FACULDADE MERIDIONAL PROGRAMA DE PÓS … LIMA DA... faculdade meridional programa de...
235
FACULDADE MERIDIONAL PROGRAMA DE PÓS-GRADUAÇÃO EM ARQUITETURA E URBANISMO MESTRADO EM ARQUITETURA E URBANISMO JULIANO LIMA DA SILVA BIM E DESIGN SCIENCE RESEARCH: PLUG-INS DE DESEMPENHO COMO FERRAMENTAS PARA CUSTOMIZAÇÃO DO PROCESSO DE PROJETO EM ARQUITETURA Passo Fundo 2018
Transcript of FACULDADE MERIDIONAL PROGRAMA DE PÓS … LIMA DA... faculdade meridional programa de...
FACULDADE MERIDIONAL
PROGRAMA DE PÓS-GRADUAÇÃO EM
ARQUITETURA E URBANISMO
MESTRADO EM ARQUITETURA E URBANISMO
JULIANO LIMA DA SILVA
BIM E DESIGN SCIENCE RESEARCH: PLUG-INS DE
DESEMPENHO COMO FERRAMENTAS PARA
CUSTOMIZAÇÃO DO PROCESSO DE PROJETO EM
ARQUITETURA
Passo Fundo
2018
Juliano Lima da Silva
BIM E DESIGN SCIENCE RESEARCH: PLUG-INS DE
DESEMPENHO COMO FERRAMENTAS PARA
CUSTOMIZAÇÃO DO PROCESSO DE PROJETO EM
ARQUITETURA
Dissertação apresentada ao Programa
de Pós-Graduação em Arquitetura e
Urbanismo da Faculdade Meridional,
na área de concentração Projeto de
Arquitetura e Urbanismo e linha de
pesquisa em Tecnologia, Projeto e
Gestão do Ambiente Construído, como
requisito parcial para obtenção do grau
de Mestre em Arquitetura e Urbanismo,
sob orientação da Dra. Andréa
Quadrado Mussi e coorientação da Dra.
Thaísa Leal da Silva.
Passo Fundo
2018
CIP – Catalogação na Publicação
S586p SILVA, Juliano Lima da
BIM e Design Science Research: plug-ins de desempenho como ferramentas para customização do processo de projeto em arquitetura / Juliano Lima da Silva. – 2018.
235 f.: il.; 30 cm.
Dissertação (Mestrado em Arquitetura e Urbanismo) – Faculdade IMED,
Passo Fundo, 2018. Orientador: Prof. Dr. Andréa Quadrado Mussi. Orientador: Profa. Dra. Thaísa Leal da Silva. 1. Arquitetura – Representação gráfica. 2. BIM. 3. Arquitetura – Programação.
I. MUSSI, Andréa Quadrado, orientadora. II. SILVA, Thaísa Leal da, orientadora. II. Título.
CDU: 72.012(035)
Catalogação: Bibliotecária Angela Saadi Machado - CRB 10/1857
Dedico este trabalho à minha
mãe e rainha, Elisabete.
AGRADECIMENTOS
Agradeço a meus pais Elisabete e Isaias pela vida e estrutura. À minha avó Hilda e
minhas irmãs Vanessa e Andressa por sempre me apoiarem e defenderem.
À minha namorada e colega de mestrado Paola Zardo pelo amor e paciência, e aos
amigos Maurício Kunz, Paola Pol Saraiva e Bruna Dal Agnol que me acompanharam
durante estes anos.
À orientadora Dra. Andréa Quadrado Mussi, coorientadora Dra. Thaísa Leal da
Silva, aos professores Dr. Lauro Ribeiro, Dra. Caliane Almeida e demais professores
do PPGARQ IMED, às professoras Dra. Elvira Lantelme e Dra. Luciana Fernandes do
PPGEC IMED, e ao professor Dr. Zacarias Chamberlain do PPGENG UPF, pelos
conhecimentos transmitidos.
Às comunidades online, canais e fóruns: Autodesk App Store, DynamoBIM,
OnDynamo, San Francisco Dynamo User Group, Philadelphia Dynamo User Group,
DynamoThoughts, Food4Rhino, Hydrashare, ProRUBIM, Solyd Treinamentos e
Github, pela disponibilidade de conteúdo e auxílio na resolução de dúvidas
encontradas.
Aos profissionais Tiago Campestrini, Anne Save de Beaurecueil, Ricardo Freitas,
Thiago Almeida, Mostapha Roudsari, Andreas Dieckmann, Milos Dimcic, Alexey
Lobanov e muitos outros, por palestras, dicas e disseminação de suas técnicas.
Agradecimentos ao Programa de Pós-Graduação em Arquitetura e Urbanismo
(PPGARQ) da Escola Politécnica da Faculdade Meridional (IMED), ao Programa de
Suporte à Pós-Graduação de Instituições de Ensino Particulares (PROSUP) e à
Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES) pelo auxílio
financeiro e bolsas que possibilitaram esta pesquisa.
"The way I see it, our fates appear to
be intertwined.
In a land brimming with Hollows,
could that really be mere chance?
So, what do you say? Why not help
one another on this lonely journey?"
-Solaire of Astora
RESUMO
A programação na arquitetura e engenharia é uma maneira interdisciplinar de
customizar soluções, ultrapassar limitações de plataformas e ampliar a capacidade de
tomada de decisão durante o processo de projeto a partir de uma abordagem de
gerenciamento de informações. No presente trabalho, busca-se compreender o papel
da programação em soluções customizadas e o fenômeno de desenvolvimento de
ferramentas por arquitetos e engenheiros a partir das extensões de VPL (Visual
Programming Languages). Como uma maneira de estudar este cenário, foi proposta a
criação de plug-ins em um software BIM (Building Information Modelling) como uma
forma de emular a situação do projetista que desenvolve suas próprias ferramentas,
com foco em uma temática específica: o atendimento de requisitos da Norma de
Desempenho Brasileira. O método utilizado para direcionar a pesquisa é o Design
Science Research, abordagem prescritiva voltada para o desenvolvimento de
artefatos vinculados a problemas específicos, que coloca o pesquisador como
principal ator em processos de desenvolvimento e avaliação das soluções
construídas. Os resultados são demonstrados pela estruturação, desenvolvimento e
posterior avaliação de dois plug-ins programados no Dynamo para o software BIM
Revit: um para a estimativa do desempenho acústico de vedações verticais, e outro
para o desempenho lumínico de iluminação natural no interior de ambientes. As
conclusões apresentam uma reflexão acerca da experiência, com considerações sobre
o potencial da programação para projetistas na adequação às particularidades de
uma grande variedade de possíveis cenários específicos, podendo tornar a
programação um fator interdisciplinar de grande importância para o futuro da
profissão.
Palavras-chave: Metodologia de Projeto, Design Science Research, BIM, Programação,
Dynamo, Norma de Desempenho.
ABSTRACT
Programming in architecture and engineering is an interdisciplinary way of
customizing solutions, overcoming platform limitations, and expanding decision-
making capability during design process from an information management
approach. In the present work, the aim is to understand the role of programming in
customized solutions and the phenomenon of tools development by architects and
engineers by the use of VPL (Visual Programming Languages) extensions. As a way
of studying this scenario, the creation of plug-ins in a BIM (Building Information
Modeling) software is proposed as a way to emulate the situation of the designer
who develops his own tools, focusing on a specific theme: meeting the requirements
of the Brazilian Performance Standard. The method used to conduct the research is
Design Science Research, a prescriptive approach focused on the development of
artifacts linked to specific problems, which places the researcher as the main actor in
processes of development and evaluation of constructed solutions. The results are
demonstrated by design, development and subsequent evaluation of two plug-ins
programmed in Dynamo for the BIM software Revit: one for estimating the acoustic
performance of walls, and another for the estimation of internal illuminance of
rooms. The conclusions present a reflection about the experience, with considerations
about the potential of programming for designers to adapt to particularities of a great
variety of possible specific scenarios, being able to make programming an
interdisciplinary factor of great importance for the future of the profession.
Keywords: Design Methodology, Design Science Research, BIM, Programming, Dynamo,
Performance Standard.
LISTA DE FIGURAS
Figura 1 - Definições sobre o termo BIM ............................................................................ 31
Figura 2 - Curva de McLeamy ............................................................................................. 32
Figura 3 - Ciclo de vida das edificações ............................................................................. 33
Figura 4 - Campos de atividade do BIM ............................................................................ 35
Figura 5 - Estágios de maturidade de projetos em BIM ................................................... 36
Figura 6 - Modelo de porta e seus parâmetros no ambiente de edição de famílias do
Revit ......................................................................................................................................... 40
Figura 7 – Consistência dos parâmetros de área e volume de uma parede com
elementos vinculados ............................................................................................................ 40
Figura 8 - Diferentes LOD de modelos BIM ...................................................................... 41
Figura 9 - Ciclo de interoperabilidade entre arquitetura e estrutura ............................. 42
Figura 10 - Colaboração entre partes interessadas no processo tradicional e BIM ...... 45
Figura 11 - Detecção de interferências entre elementos estruturais e de sistemas
prediais .................................................................................................................................... 46
Figura 12 - Progamação de elementos no Generative Components .............................. 49
Figura 13 - Importando geometria programada como elementos BIM no Archicad .. 50
Figura 14 - Parametrização de um elemento de pilar no Dynamo e sua visualização
no Revit ................................................................................................................................... 51
Figura 15 – Operações em painél com programação no Marionette .............................. 51
Figura 16 - Localização do Dynamo na interface do Revit .............................................. 53
Figura 17 - Anatomia básica de um nodo .......................................................................... 53
Figura 18 - Funcionamento de wires ligando informações aos nodes ........................... 54
Figura 19 – Exemplos de inputs possíveis na interface do Dynamo .............................. 55
Figura 20 - Importando informações de parâmetros de uma parede do Revit ............ 55
Figura 21 - Funcionamento de sequências, listas e operações matemáticas ................. 56
Figura 22 - Funcionamento de condicionantes lógicos por 3 maneiras: node If,
fórmula, e Code Block ............................................................................................................. 57
Figura 23 - Convertendo de visual para DesignScript textual ......................................... 58
Figura 24 - Estruturação interna de um node customizado do pacote Lunchbox ....... 59
Figura 25 - Estruturação interna de um node Python Script ............................................ 60
Figura 26 - Rotina para composição de estrutura utilizando componentes adaptivos
.................................................................................................................................................. 61
Figura 27 - Botões de interface no Revit criados a partir da programação do Dyno
Browser ................................................................................................................................... 61
Figura 28 - Edição de parâmetros preset e resultados da execução de uma rotina pelo
Revit ......................................................................................................................................... 62
Figura 29 - Exemplos de interfaces configuráveis no Data-Shapes ................................ 64
Figura 30 - Componentes do Ladybug Tools .................................................................... 65
Figura 31 - Coleção de funcionalidades do pacote Ladybug .......................................... 66
Figura 32 - Coleção de funcionalidades do pacote Honeybee ........................................ 66
Figura 33 - Aplicação de Ladybug Tools no Dynamo para estudos de painéis solares
.................................................................................................................................................. 67
Figura 34 - Quadro de exigências de desempenho ........................................................... 75
Figura 35 - Etapas da pesquisa ............................................................................................ 92
Figura 36 - Esquema básico de desenvolvimento de plug-ins ........................................ 97
Figura 37 - Esquema de funcionamento geral dos plug-ins ............................................ 98
Figura 38 - Índices de redução sonora individuais e do sistema .................................. 103
Figura 39 - Criação de Shared Parameters para acústica no Revit ............................... 105
Figura 40 - Fluxograma da função (1) Calcular Rw ........................................................ 107
Figura 41 - Fluxograma da função (2) Verificar Desempenho ...................................... 109
Figura 42 - Fluxograma da função (3) Reset para o plug-in de desempenho acústico
................................................................................................................................................ 110
Figura 43 - Fluxograma da função (4) Ajuda para o plug-in de desempenho acústico
................................................................................................................................................ 111
Figura 44 – Parâmetros registrados nas propriedades dos elementos ......................... 112
Figura 45 – Vista de planta baixa com famílias de parede e esquadrias cadastradas 112
Figura 46 - Código em Python para organização de listas e instâncias de paredes ... 113
Figura 47 - Ambiente Dynamo e definição de intersecções entre planos e geometria
de janelas ............................................................................................................................... 114
Figura 48 - Janela para definição do valor médio de Rw ............................................... 115
Figura 49 - Configurações de condicionantes para os filtros criados (desempenho
acústico)................................................................................................................................. 115
Figura 50 - Configurações de visibilidade para os filtros criados (desempenho
acústico)................................................................................................................................. 115
Figura 51 - Resultados do cálculo e verificação de modelos ......................................... 116
Figura 52 - Janela de opções da função (4) Ajuda ........................................................... 117
Figura 53 - Aba de funções de desempenho e ícones para desempenho acústico ..... 117
Figura 54 - Navegador do Dyno Browser e as rotinas configuradas ........................... 118
Figura 55 - Arquivo de texto do Dyno Browser e sua configuração ............................ 118
Figura 56 – Pasta contendo rotinas do plug-in para acústica e suas respectivas
imagens de ícone .................................................................................................................. 119
Figura 57 - Criação de Shared Parameters para iluminação no Revit ......................... 121
Figura 58 - Fluxograma da função (1) Gerar Grid .......................................................... 123
Figura 59 - Fluxograma das funções (2) Análise Lux e (3) Análise FLD ..................... 125
Figura 60 - Fluxograma da função (4) Reset para o plug-in de desempenho lumínico
................................................................................................................................................ 126
Figura 61 - Fluxograma da função (5) Ajuda para o plug-in de desempenho lumínico
................................................................................................................................................ 126
Figura 62 - Janela de opções de input para a função (1) Gerar Grid ............................ 128
Figura 63 - Malha de elementos genéricos dentro de um ambiente ............................ 128
Figura 64 - Traçado das trajetórias do sol, vista superior e tridimensional ................ 129
Figura 65 - Preenchimento da malha com os resultados para iluminância ................ 129
Figura 66 - Configurações de condicionantes para os filtros criados (desempenho
lumínico) ............................................................................................................................... 130
Figura 67 - Configurações de visibilidade para os filtros criados (desempenho
lumínico) ............................................................................................................................... 130
Figura 68 - Modelagem 3D de ambientes com diferentes configurações de aberturas
................................................................................................................................................ 131
Figura 69 - Resultados da análise para os ambientes em vista de planta baixa ......... 132
Figura 70 - Projeto exemplo para análise de desempenho lumínico ........................... 133
Figura 71 - Resultados da análise de iluminância no projeto exemplo em diferentes
horários ................................................................................................................................. 133
Figura 72 - Customização das escalas de cor para uma escala de desempenho no
projeto exemplo ................................................................................................................... 134
Figura 73 - Janela de opções da função (5) Ajuda ........................................................... 135
Figura 74 - Aba de funções de desempenho e ícones para desempenho lumínico.... 135
Figura 75 - Quadro de respostas para a função (1) Calcular Rw .................................. 140
Figura 76 - Quadro de respostas para a função (2) Verificar desempenho ................. 140
Figura 77 - Quadro de respostas para a função (3) Reset no plug-in para desempenho
acústico .................................................................................................................................. 141
Figura 78 - Quadro de respostas para a função (4) Ajuda no plug-in para
desempenho acústico .......................................................................................................... 141
Figura 79 - Quadro de respostas para a função (1) Gerar Grid ..................................... 143
Figura 80 - Quadro de respostas para a função (2) Análise Lux ................................... 144
Figura 81 - Quadro de respostas para a função (3) Análise FLD .................................. 144
Figura 82 - Quadro de respostas para a função (4) Reset para o plug-in de
desempenho lumínico ......................................................................................................... 145
Figura 83 - Quadro de respostas para a função (5) Ajuda para o plug-in de
desempenho lumínico ......................................................................................................... 145
LISTA DE TABELAS
Tabela 1 - Valores indicativos do índice de redução sonora ponderado para alguns
sistemas de paredes ............................................................................................................. 106
Tabela 2 - Diferença padronizada de nível ponderada entre ambientes ..................... 108
Tabela 3 - Índice de redução sonora ponderado para fachadas ................................... 109
Tabela 4 - Captura de informações necessárias no plug-in de desempenho lumínico
................................................................................................................................................ 122
Tabela 5 - Níveis de iluminância para iluminação natural ............................................ 124
Tabela 6 - Fator de luz diurna para os diferentes ambientes da habitação ................. 124
Tabela 7 - Questionamentos para avaliação do plug-in de desempenho acústico .... 137
Tabela 8 - Questionamentos para avaliação do plug-in de desempenho lumínico ... 137
Tabela 9 - Avaliação dos plug-ins por aspectos de uso específicos.............................. 138
LISTA DE ABREVIATURAS E SIGLAS
AEC - Arquitetura, Engenharia e Construção
ABNT - Associação Brasileira de Normas Técnicas
API - Application Programming Interface
BDA – Building Design Advisor
BIM - Building Information Modeling
BREEAM - Building Research Establishment Environmental Assessment Method
BSI - British Standards Institution
CAD - Computer-Aided Design
CBIC - Câmara Brasileira da Indústria da Construção
CFD - Computational Fluid Dynamics
EPW - Energy Plus Weather file
FLD - Fator de Luz Diurna
IAI - International Alliance for Interoperability
IFC - Industry Foundation Classes
IPD – Integrated Project Delivery
ISO - International Organization for Standardization
ITA - Instituição Técnica Avaliadora
LEED - Leadership in Energy and Environmental Design
LOD - Level of Development
MEP - Mechanical, Electrical and Plumbing
TPL - Textual Programming Language
viDCO – virtually integrated Design, Construction and Operation
VPL - Visual Programming Language
VUP - Vida Útil de Produto
SUMÁRIO
1. INTRODUÇÃO ......................................................................................... 16
2. BUILDING INFORMATION MODELING ........................................ 30
2.1 Parametrização ........................................................................................................ 38
2.2 Interoperabilidade ................................................................................................. 41
2.3 Colaboração ............................................................................................................. 44
3. PROGRAMAÇÃO VISUAL EM SOFTWARES BIM ........................ 47
3.1 Dynamo .................................................................................................................... 52
3.1.1 Dyno Browser...................................................................................................... 61
3.1.2 Data-shapes ......................................................................................................... 63
3.1.3 Ladybug e Honeybee ......................................................................................... 65
4. PERFORMANCE DAS EDIFICAÇÕES ............................................... 68
4.1 BIM aplicado à performance ................................................................................ 68
4.2 Norma de Desempenho Brasileira ...................................................................... 74
4.3 BIM e a Norma de Desempenho ......................................................................... 78
5. DESIGN SCIENCE RESEARCH ............................................................ 81
5.1 O paradigma Design Science ............................................................................... 81
5.2 O método Design Science Research ................................................................... 84
5.2.1 Artefatos ............................................................................................................... 85
5.2.2 Rigor e Relevância .............................................................................................. 87
5.2.3 Classes de problemas e generalização ............................................................ 90
5.3 Etapas da pesquisa ................................................................................................. 91
5.3.1 Definições para o desenvolvimento dos artefatos ....................................... 95
5.3.2 Definições para a avaliação de artefatos ........................................................ 99
6. PLUG-INS DESENVOLVIDOS ........................................................... 102
6.1 Plug-in I: desempenho acústico de vedações verticais ................................ 102
6.1.1 Projeto do Plug-in I .......................................................................................... 104
6.1.2 Funcionamento e desenvolvimento do Plug-in I ....................................... 111
6.2 Plug-in II: desempenho lumínico de ambientes internos ............................ 119
6.2.1 Projeto do Plug-in II ........................................................................................ 121
6.2.2 Funcionamento e desenvolvimento do Plug-in II...................................... 127
7. AVALIAÇÃO DOS PLUG-INS ............................................................ 136
7.1 Questionário para avaliação ............................................................................... 136
7.2 Experiência de entrevista .................................................................................... 138
7.2.1 Discussões e feedback – Plug-in I ................................................................. 139
7.2.2 Discussões e feedback – Plug-in II ............................................................... 142
7.3 Considerações finais sobre a avaliação ............................................................ 146
8. CONCLUSÕES ........................................................................................ 147
8.1 Diretrizes para o desenvolvimento de plug-ins em software BIM ............ 149
8.2 Generalização para classe de problemas ......................................................... 153
8.3 Reflexões e posicionamento sobre a experiência ........................................... 155
8.4 Trabalhos futuros e recomendações ................................................................. 158
REFERÊNCIAS BIBLIOGRÁFICAS ......................................................... 160
16
1. INTRODUÇÃO
Este trabalho se refere à temática de metodologias de projeto, no âmbito da
customização de processos, por meio da apresentação da programação em softwares
BIM (Building Information Modeling) como um aspecto emergente para os
profissionais projetistas, por meio da criação de soluções voltadas para problemas
específicos da área em que atuam. Para caracterizar este contexto e os desafios dos
profissionais perante esta abordagem, este capítulo inicialmente descreve o cenário
de inovações e novas tecnologias. Então, é apresentado como a programação de
ferramentas pelos próprios projetistas pode influenciar este contexto.
Em seguida, é apresentada a estratégia de condução da pesquisa, onde é proposto o
desenvolvimento de ferramentas por meio de programação e o método escolhido
para alcançar os objetivos – Design Science Research. Então, é apresentada a
delimitação de um tema específico para possibilitar ao pesquisador emular o cenário
descrito por meio da programação. Por fim, a estruturação do trabalho e organização
dos capítulos é apresentada.
Projetar edificações é uma atividade interdisciplinar, que envolve conhecimentos
advindos de uma diversidade de áreas – desde concepção, aspectos espaciais e de
ocupação humana, durabilidade e resistência estrutural, soluções em sistemas
prediais elétricos, hidráulicos e de climatização, bem como o comportamento das
edificações em termos de conforto, qualidade e desempenho dos sistemas
construtivos. Tais aspectos são manifestados pelos profissionais envolvidos no
processo de projeto por meio de sua capacidade de tomar decisões e, nestas
situações, sistemas computacionais podem complementar as atividades humanas,
tornando disponíveis as informações necessárias e, possibilitando realizar escolhas
informadas e de maneira tempestiva (EASTMAN, 1981).
Dentre as tecnologias, destacam-se os softwares CAD (Computer-Aided Design),
introduzidos nos escritórios de arquitetura no final do século 20, fazendo com que as
atividades de desenho em papel aos poucos fossem substituídas pelos softwares, os
quais proporcionavam maior produtividade nos processos de trabalho. Embora isto
tenha causado uma redução no número de profissionais desenhistas, tal fato
possibilitou ao campo de arquitetura uma nova interface – a inclusão de conceitos de
tecnologia da informação, o que amplificou o potencial de complexidades no
ambiente projetual (CELANI et al., 2015).
Com este avanço das tecnologias no ambiente de projeto, houve também o
surgimento de novas competências para os profissionais de arquitetura e engenharia
civil, possibilitando a utilização de diversas ferramentas computacionais para dar
17
suporte ao desenvolvimento de projetos, visando o aumento da confiabilidade das
informações de uma construção. Tais competências agregaram ao mérito destas
profissões e se tornaram mais aparentes conforme os níveis de informações dos
projetos aumentaram (GARBER, 2009).
Para Celani et al. (2015), assim como a inovação tecnológica fez com que a maneira
como arquitetos trabalhavam em relação ao desenho em papel evoluísse, com
softwares CAD substituindo atividades manuais e repetitivas, algo semelhante
poderá acontecer conforme a evolução do contexto tecnológico requerer uma nova
gama de competências de seus profissionais.
Em um cenário cada vez mais competitivo, o setor AEC (Arquitetura, Engenharia e
Construção) está requisitando uma quantidade cada vez maior de informações
relativas às soluções de custo, performance e gerenciamento, que remetem à
interdisciplinaridade projetual. Os projetistas precisam abraçar as novas abordagens,
ou correm o risco de terem seu papel severamente diminuído ou substituído por
profissionais com as novas competências exigidas pelo mercado (HOLZER, 2015).
Além disso, conforme o número de soluções inovadoras aumenta, também aumenta
a necessidade de associar decisões de projeto à nova complexidade introduzida,
dificultando a aplicação de métodos ou ferramentas simplificadas. Como
profissionais, arquitetos e engenheiros agregam valor aos projetos por suas decisões
e, portanto, devem interpretar a vasta informação disponível, aplicando-a de maneira
eficiente em seus processos (PITTMAN, 2003).
Neste sentido, o problema de gerenciamento de informações é agravado quando as
decisões envolvem, além de aspectos quantitativos, aspectos qualitativos de difícil
inserção no ambiente computacional, que exigem a capacidade do projetista além da
automatização dos processos (PAPAMICHAEL, 1998). Pois, enquanto que a predição
de fatores como a performance das edificações pode ser automatizada por meios
computacionais, a avaliação das escolhas qualitativas de projeto torna-se mais
complicada, a não ser que seja em respeito a um único critério. Assim, segundo
Papamichael (1998), é esta necessidade de adaptar um projeto a soluções multi-
critérios, de variadas naturezas e complexidades, que torna o papel do projetista
imprescindível, mesmo em uma era digital, onde os computadores otimizam muitas
das suas atividades.
Esta necessidade de melhorar o gerenciamento das informações de diversas
naturezas em projetos foi um dos motivos que levou à ascenção do BIM, modificando
radicalmente o paradigma no qual os arquitetos e engenheiros estavam inseridos na
medida em que seus processos de projeto se tornaram mais colaborativos, integrados
e interdisciplinares (GARBER, 2009). Desse modo, para incluir informações
18
qualitativas diretamente nos projetos, novos parâmetros podem ser criados a partir
das propriedades iniciais de elementos BIM, possibilitando flexibilizar o uso da
informação para uma diversidade de finalidades, o que a torna expansível para
muitos contextos (SHELDEN, 2009). É possível incorporar informações ao modelo
para incluir até mesmo aspectos estéticos, socioculturais, políticos e históricos –
desde que os bancos de dados originários possuam abundância de correlações
(massive data) e regras bem definidas (OTTCHEN, 2009). Desta maneira, atividades
não rotineiras também podem ser automatizadas até certo ponto, se a informação
disponível ao projetista for suficiente (CELANI et al., 2015).
Imagina-se um cenário onde todos os projetistas possam compartilhar as informações
de suas instâncias de projeto em um mesmo ambiente. Um modelo tridimensional
dotado de informações precisas, inteligentes e interconectadas entre as disciplinas,
onde os profissionais podem ter acesso a informações relevantes a seu projeto no
momento em que precisam, de modo que trabalhem de forma coordenada. Tal
cenário é alcançável por meio da implementação do BIM nos processos de projeto.
Pois, enquanto que as informações acionáveis de um desenho feito em software de
desenho 2D dependem exclusivamente da interpretação dos projetos, em modelos
BIM é possível incluir informações semânticas ricas em dados, que vão além das
dimensões de formas arquitetônicas, para agregar conhecimento acerca de
performance, função e custo – aspectos que compõem uma edificação real
(PITTMAN, 2003).
Porém, para que isto continue acontecendo e evoluindo, é necessária uma mudança
no paradigma de desenvolvimento projetual, rever e transformar os processos de
projeto já estabelecidos e industrializar a produção destes (BUILDINGSMART, 2017).
Assim, as escolhas de materiais e soluções tecnológicas passam a ter um aspecto
privilegiado: a análise de aspectos de produção, comportamento e viabilidade
econômica muito antes de sua implementação (OTTCHEN, 2009), reduzindo as
incertezas e riscos em relação a custo, prazo e performance de materiais por meio da
transparência das propriedades de seus objetos, tornando possível antecipar as
causas e efeitos das decisões tomadas (GAUCHAT, 2009).
Além disso, com a utilização do BIM, profissionais passaram a compreender novas
possibilidades em seus processos de projeto, deixando de utilizar ferramentas
computacionais de desenho 2D apenas para gerar documentação, mas também para
realizar análises e simulações em ambientes 3D, explorando múltiplas alternativas de
projeto para suplementar suas decisões. Uma mudança também está ocorrendo em
relação às habilidades necessárias para avaliar tais alternativas: enquanto que por
vezes o sucesso de uma solução de projeto é ancorado somente na experiência e
19
intuição de grandes projetistas, a abundância de informações e ferramentas permite
que um grau maior de flexibilidade e precisão possa ser conquistado, desde que as
informações inseridas sejam fiéis e coerentes (KEOUGH; HAUCK, 2017).
As perspectivas baseadas no uso de informações do modelo se estendem pelo ciclo
de vida da edificação ao longo do tempo (simulações 4D e outras dimensões). Estas
possibilidades de interação aliadas às capacidades paramétricas e generativas de
muitas das ferramentas BIM, permitem que projetistas desafiem a maneira
tradicional de projetar e construir (GARBER, 2009).
A concepção de projetos também pode ser potencializada pelo uso destes softwares.
A janela de possibilidades para o arquiteto explorar diferentes alternativas é algo
abordado no design paramétrico, performativo, generativo e evolutivo das
edificações, exigindo, contudo, um maior grau de abstração e uma série de outras
competências relacionadas à tecnologia da informação para que possam ser
utilizadas efetivamente (CELANI et al., 2015). Com isto, novas tecnologias
possibilitam não somente amplificar a criatividade de arquitetos, mas integrá-la a
outras disciplinas nas etapas iniciais (GARBER, 2009).
Com isto, alguns autores vêm reimaginando o papel dos profissionais arquitetos e
engenheiros do futuro. Segundo Holzer (2015), as consequências do avanço do BIM e
Design Paramétrico alteram profundamente o papel do arquiteto e engenheiro, pois
modificaram a maneira como projetos são pensados, desenvolvidos e
compartilhados. Isto está evidenciando o uso da computação nos projetos, que se
estende além do mero uso das ferramentas para representação gráfica (GARBER,
2009).
Para Keough e Hauck (2017), os projetistas do futuro terão um escopo muito maior
de alternativas para soluções de projeto, e terão a necessidade de implementar a
computação intensivamente em seus processos – por meio da otimização,
gerenciamento de informações, design generativo e adaptivo.
Conforme Pittman (2003), o desafio do projetista do futuro é desenvolver
ferramentas que possibilitem o consumo de informações de forma interoperável e
digital – em detrimento da impressão em papel ou mera geração de documentos.
Para tal, são necessários mecanismos que possibilitem a análise dos aspectos de
performance, função e custo de seus projetos – ferramentas integradas inseridas no
paradigma de projeto do BIM.
Uma grande preocupação de projetistas é de que os computadores irão substituir
suas habilidades ou torná-las obsoletas. Contudo, a computação na arquitetura ainda
possui um grande foco no aspecto da produtividade de geração de documentação e
20
gerenciamento de informações – atividades que não envolvem, ou pouco influenciam
na criatividade artística dos profissionais (CELANI et al., 2015).
Os autores reforçam que, as etapas de cálculo, simulações térmicas, lumínicas e
acústicas, verificações de desempenho e normatização (code checking) são
automatizáveis pois envolvem características de componentes e materiais, relações
semânticas entre tais componentes e, principalmente, regras ou etapas bem definidas,
diferentemente da concepção, que dificilmente é programável.
Diante destas situações, Gauchat (2009) defende que, embora inicialmente se pense
que o projetista que utiliza software de desenho 2D meramente será substituído pelo
projetista que utiliza BIM, a crescente complexidade de projetos e a necessidade de
inovar, projetar eficientemente e economizar no setor AEC tornará o projetista BIM
um profissional que precisa de sólida interdisciplinariedade, habilidade e poder para
tomar decisões.
Por ampliar a possibilidade de agregar valor à construção, o BIM pode modificar
radicalmente a profissão dos arquitetos e engenheiros na medida em que aumenta
sua responsabilidade e poder de desenvolver soluções inovadoras no ambiente de
projeto (GAUCHAT, 2009). Tais responsabilidades adquiridas colocam o arquiteto ou
engenheiro como um profissional novamente no centro dos processos, pois toda
informação acerca da edificação é contida nos modelos de informação (GARBER,
2009).
Este cenário é de muito mais impacto no design, construtibilidade e custo das
edificações (PITTMAN, 2003). Portanto, com uma importância muitas vezes maior
que a tradicionalmente percebida – do projetista que apenas desenha, elevando as
profissões para um novo patamar – do projetista que ativamente soluciona e toma
decisões significativas, reiteradas pela abundante quantidade de informação e
ferramentas sofisticadas de simulação.
Contudo, conforme a complexidade e a abundância de informações de múltiplas
disciplinas são inseridas em modelos BIM, se faz necessário desenvolver novas
soluções que tratem tais informações de forma adequada e as considerem,
efetivamente, no processo de projeto de engenheiros e arquitetos (GARBER, 2009).
Surgem novamente, competências para que estas profissões atuem de maneira ótima.
Dentre tais competências, Holzer (2015) destaca o Scripting ou Programação, como
algo que ainda possui um papel que está sendo descoberto na arquitetura.
Em relação a esta competência interdisciplinar entre a arquitetura e a tecnologia da
informação, alguns escritórios renomados na área de arquitetura têm investido em
contratar programadores, visando desenvolver soluções específicas para seus
21
problemas de concepção projetual, exemplos disto são: Arup, Foster & Partners e
Zaha Hadid (CELANI et al., 2015).
Contudo, há uma grande lacuna entre o projetista que simplesmente sabe utilizar
ferramentas e softwares comerciais – necessitando apenas de treinamento, e o
projetista que possui conhecimento interdisciplinar entre arquitetura e computação,
ou tecnologia de informação (CELANI et al., 2015).
Além disso, a programação em softwares de arquitetura por vezes não é realizada
por arquitetos e sim por profissionais exclusivamente de áreas da computação ou
afins. Aish (2003) acredita em uma lacuna neste contexto e questiona: “existe um
encontro entre as mentes dos projetistas criativos que utilizam os sistemas CAD e os
engenheiros de software que os desenvolveram?” (tradução nossa, AISH, 2003, p.
338).
Para responder esta pergunta, em outra pesquisa, Aish (2013a) relata que a história
do CAD está atualmente passando por algo chamado de era Design Computation,
onde se busca ultrapassar limitações de plataformas e amplificar potenciais de
softwares a partir do aproveitamento da programação em projetos – que se manifesta
por meio da otimização, gerenciamento de dados, design generativo e evolutivo,
desenvolvido pelos próprios projetistas.
Nesta nova realidade, “o papel do arquiteto deve ser reconceituado daquele de um
gênio romântico ou um guru tecnológico, para um estrategista multidisciplinar”
(tradução nossa, OTTCHEN, 2009, p.25).
Para Whitehead, (2003, p.148), a figura do arquiteto programador é um desafio: “a
maioria dos projetistas já pensa programaticamente, mas não possui nem o tempo
nem inclinação para aprender habilidades de programação, não possuindo as
maneiras de expressar ou explorar estes padrões de pensamento”. Confome o autor,
na medida em que os projetos se tornam mais complexos, únicos e ricos em
informação, cada vez mais se torna necessário empregar tais competências.
Para elucidar este contexto, é necessário conhecer a funções da programação na
arquitetura. Leitão, Santos e Lopes (2012) conceituam que programação na
arquitetura pode ser entendida como a representação de processos algorítmicos que
expressam conceitos arquitetônicos ou resolvem problemas de natureza
arquitetônica. A programação pode facilitar a criação de formas complexas, cuja
definição seria muito difícil, trabalhosa ou impossível utilizando apenas
funcionalidades básicas (AISH, 2013b). Além disso, o projetista pode deixar que os
algoritmos realizem o trabalho “braçal” de efetuar verificações quantitativas,
22
utilizando as informações disponibilizadas para ampliar aspectos de criatividade
(OTTCHEN, 2009).
Contudo, mais do que isto, softwares de arquitetura devem possibilitar o processo
exploratório de design – a criação e manipulação de relações geométricas e a
interpretação dos impactos decorrentes, facilitando o processo de tomada de decisão,
ao passo em que amplificam as habilidades intelectuais do usuário (AISH, 2003).
Para o cenário de projetos, inovações na automatização e integração não significam
que os projetos serão totalmente automatizados, mas sim que possibilitarão aos
projetistas dedicar mais tempo e ter mais liberdade para atuar nas decisões
importantes – soluções projetuais, em detrimento das atividades operacionais e de
baixo impacto.
Em relação às demandas de programação de projetistas, Aish (2003) relata que
muitos dos softwares CAD possuem interfaces focadas apenas na geração de
documentação gráfica, não atendendo à exploração da criação e customização de
maneira integrada. O autor afirma que os recursos para tal exploração existem,
escondidos nas linhas de comando e funções internas dos softwares, “para um
projetista com habilidades de programação, isto proporciona um recurso
extremamente poderoso” (tradução nossa, AISH, 2003, p. 340). Para Garber (2009),
muitas das características generativas e scripts de programação dos softwares BIM
são despercebidos ou não utilizados por muitos projetistas, sendo necessário trazer o
foco do processo de projeto para a exploração de soluções alternativas ao invés da
mera representação gráfica ou documental das escolhas (AISH, 2013a, 2013b).
Considerando que a computação está fortemente inserida no cotidiano profissional
do projetista, Aish (2003) destaca que a presença de interfaces de programação em
softwares CAD é primordial para possibilitar o processo de projeto exploratório.
Além disso, a competência de projetistas em programar se torna necessária para
atingir o completo potencial de uso de suas ferramentas de trabalho, pois abre portas
para numerosas interações e refinamentos nos modelos.
Contudo, muitos dos problemas específicos de projetistas não são contemplados
apenas nas interfaces básicas de suas plataformas, onde muitas das funcionalidades
acabam por ser demasiadamente conservadoras (FERREIRA; LEITÃO, 2015). Além
disto, funcionam como uma “caixa preta” com funcionalidades restritas, impedindo
que o usuário interaja com a informação em situações de maior complexidade devido
a limitações inerentes e/ou necessidades de inputs muito específicos (AISH; MARSH,
2011). Isto reforça a necessidade pela busca por soluções customizadas – e
programadas pelos próprios projetistas.
23
Nesta situação, surge a figura do projetista programador, um arquiteto, engenheiro
ou designer, com competências relacionadas ao uso de softwares para modelagem de
informação, capaz de atuar diretamente sobre seus problemas de projeto através da
implementação de códigos de programação e da utilização de ferramentas
customizadas. Desagregando-se e tornando-se mais independente de softwares
comerciais, de grandes plataformas, e de software houses, as quais possuem soluções
direcionadas, muitas vezes criadas por profissionais da computação que não são das
áreas de engenharia ou arquitetura.
Para Mackey e Roudsari (2018), o problema das grandes empresas de software
comercial se estende ainda mais: muitas destas preferem adicionar funcionalidades
que imitem as de seus concorrentes ao invés de construir pontes de
interoperabilidade com eles, o que prejudica o projetista muito mais do que ajuda. Os
autores pontuam que a programação é uma maneira de colocar o poder de realizar
tal interoperabilidade ao alcance do próprio projetista – ressaltando ainda mais sua
crescente responsabilidade, conforme descrito anteriormente.
Para tornar isto possível, muitas das plataformas BIM para modelagem arquitetônica
como o Revit contam com um API (Application Programming Interface), onde é
possível interagir com as funcionalidades internas da plataforma por meio da criação
de plug-ins e extensões. Contudo, por utilizar linguagens de programação textuais
(como C#), programar pela API pode se tornar uma tarefa árdua e que consome
muito tempo para arquitetos e engenheiros iniciantes em programação (FERREIRA;
LEITÃO, 2015).
O desafio é encorajar praticantes de arquitetura, engenharia e design com pouco
conhecimento acerca de programação a programar, visto que este novo paradigma é
encarado como uma barreira de abstração (AISH, 2013b).
Com estes problemas, visando as novas competências dos projetistas futuros e sua
independência, é necessário atribuir ao arquiteto ou engenheiro a função de criador
de suas próprias soluções, respeitando seu progresso e aprendizado sobre
programação. Alternativas estão presentes nas ferramentas da era Design Computation
(AISH, 2013a) por meio dos softwares que operam utilizando VPL (Visual
Programming Language). São softwares classificados como extensões das grandes
plataformas de modelagem e softwares BIM, que permitem a parametrização da
informação advinda de modelos, possibilitando a criação de geometrias complexas e
o gerenciamento avançado de informações. Alguns exemplos de tais softwares são
GenerativeComponents, Dynamo, Grasshopper e Marionette (BENTLEY, 2018;
DYNAMO, 2018a; GRASSHOPPER, 2018; VECTORWORKS, 2018).
24
Nas VPLs, os programas são formados por componentes ou nodos que se interligam
por fios, levando diferentes formas de informação de um nodo a outro linearmente,
cada nodo contém um código de programação textual interno, que inicialmente não é
visível para o usuário. Já nas TPLs (Textual Programming Language), as rotinas são
compostas por uma sequência de caracteres com significados semânticos e que
realizam o encadeamento lógico por meio do texto conhecido como script ou código
(LEITÃO; SANTOS; LOPES, 2012).
Os softwares de VPL se tornaram uma alternativa muito atrativa para os projetistas,
pois possuem uma interface simples, intuitiva, de fácil aprendizado e não requerem,
inicialmente, muito conhecimento acerca de programação (FERREIRA; LEITÃO,
2015). Além destas vantagens, possibilitam ao projetista obter um feedback visual
imediato da programação realizada e interatividade para definir e regular
parâmetros. Tais motivos levaram as extensões de VPL como Grasshopper a se
tornarem muito mais populares que as interfaces de programação textual (LEITÃO;
SANTOS; LOPES, 2012).
O processo BIM também amplia o potencial destas extensões de programação pois
permite que parâmetros de materiais oriundos de aspectos de desempenho e
produção sejam incorporados nas rotinas (AISH; MARSH, 2011), possivelmente
efetuando análises muito mais complexas do que apenas manipulações de forma
presentes em softwares que não estejam inseridos no processo BIM e realizem
somente manipulações geométricas.
Dentre as extensões de VPL que operam no processo BIM está o Dynamo, que
permite a usuários ter acesso a opções de manipulação da informação de forma
flexível e em etapas cada vez mais iniciais de projeto (HOLZER, 2015). Usuários de
Dynamo podem operá-lo para criar suas próprias regras de gerenciamento de
informações e virtualmente construir diversos utilitários para alavancar a avaliação
do modelo e etapas do processo de projeto como um todo por meio de rotinas de
programação que podem ser editadas, reconfiguradas e reaproveitadas em diversas
construções, reduzindo a dependência a outros softwares (SEGHIER et al., 2017).
Aish (2013b) ressalta que, embora extensões como Grasshopper e Dynamo fossem
atrativas para projetistas com pouca ou nenhuma experiência em programação,
softwares robustos programados em VPL possuiam problemas de escalabilidade –
tornavam-se de difícil manutenção conforme sua complexidade e não atendiam as
necessidades de programadores mais experientes. Neste sentido, o DesignScript –
uma linguagem de programação textual previamente existente, foi inserida nas
extensões VPL de softwares CAD, e foi criada como uma maneira de mitigar
algumas das limitações de programação inicialmente encontradas por meio da
25
inserção de conceitos de TPL nas interfaces de VPL (AISH; MARSH, 2011; AISH et
al., 2012; LEITÃO; SANTOS; LOPES, 2012).
A intenção por trás da implementação do DesignScript foi ultrapassar as barreiras de
aprendizado de projetistas novatos em programação por meio da integração entre
programação visual e textual (AISH; MENDOZA, 2016).
O DesignScript permite que projetistas, em diversos níveis de conhecimento acerca de
programação visual e/ou textual, utilizem os componentes para criar seus próprios
programas para manipular a modelagem (AISH et al., 2012). Isto torna o projetista
ainda mais independente dos softwares comerciais na medida em que possibilita que
resolva muitos de seus entraves e particularidades por conta própria, não
necessitando esperar que os grandes desenvolvedores criem funcionalidades
específicas na interface das plataformas.
A presença de nodos ou componentes para linguagens textuais como C# ou Python
presentes nas extensões possibilita mitigar o problema de escalabilidade (AISH,
2013b). Tais opções também são conhecidas como componentes híbridos e permitem
que o usuário inicie seu aprendizado sobre TPL enquanto utiliza a extensão de VPL
(LEITÃO; SANTOS; LOPES, 2012).
Aish e Mendoza (2016) ressaltam que as programações visual e textual podem se
complementar, em variados graus de intensidade e complexidade, ao longo do
aprendizado do projetista em relação à criação de suas soluções. Conforme as rotinas
desenvolvidas se tornam mais complexas, Ferreira e Leitão (2015) defendem o uso de
linguagens de programação textual concomitantemente com as visuais através dos
componentes híbridos.
Para Aish (2013a), o principal mérito das extensões de VPL é a origem de um
ambiente onde projetistas e desenvolvedores podem compartilhar ideias em
comunidade, para solucionar problemas de variadas espécies, a partir da criação de
suas próprias soluções: “antes de projetar, vou primeiro construir minhas
ferramentas”(tradução nossa, AISH, 2013a, p.49).
Este cenário fomenta a criação das comunidades de projetistas programadores,
fóruns virtuais onde os membros discutem e produzem suas soluções customizadas,
auxiliando uns aos outros no processo de aprendizado e criação de rotinas de
programação, por vezes disponibilizando-as para que outros testem e avaliem seus
códigos. Alguns exemplos de tais fórums são o DynamoBIM, Food4Rhino, Ladybug,
Hydra entre outros (DYNAMO, 2018b; FOOD4RHINO, 2018; HYDRA, 2018;
LADYBUG, 2018).
26
Por muitas destas extensões serem de código aberto, é permitido que usuários
avançados contribuam com o sistema por meio da definição de novos nodes
componentes, que por sua vez podem ser utilizados e avaliados pelos outros
usuários (AISH; MENDOZA, 2016).
A divisão de funções em componentes ou nodos transforma as extensões VPL em
verdadeiras “caixas de ferramentas” (MACKEY; ROUDSARI, 2018), permitindo que
as soluções criadas por usuários sejam altamente customizáveis e compartilháveis.
Muitas das extensões VPL são softwares de código aberto e, portanto, encorajam tal
comportamento.
Membros da comunidade com diversos níveis de habilidade em programação
podem, então, se ajudar tanto no aprendizado das extensões VPL como no
desenvolvimento de suas “caixas de ferramentas” (MACKEY; ROUDSARI, 2018).
Além disso, como tais extensões são de código aberto, usuários avançados podem
contribuir para a construção de componentes já existentes, que eventualmente serão
atualizados e utilizados pela comunidade, gerando um ciclo virtuoso: “permitir que
todos visualizem o código fonte de uma ferramenta é um convite para se tornar
mestre da mesma” (tradução nossa, MACKEY; ROUDSARI, 2018, p. 101).
Segundo Aish (2003, p. 347):
[...] o software apenas atinge a conclusão completa através de seu uso e
extensões adicionadas por usuários criativos [...] a melhor marca do sucesso
são as extensões que o desenvolvedor original não antecipou, aquelas que
refinam ou ampliam a abstração subjacente.
Compreender este fenômeno de criação de ferramentas únicas e de mudança do
papel do arquiteto é de relevância tanto para o cenário profissional, pois envolve um
novo paradigma de desenvolvimento de projeto – uma nova maneira de solucionar e
tomar decisão nos processos, como para o cenário acadêmico, pois pode impactar a
educação e a formação de novos projetistas na era digital – em relação à competência
de programar e à formação de arquitetos e engenheiros multidisciplinares.
Para a compreensão do fenômeno, é necessário um posicionamento crítico acerca
destas atividades. Como uma maneira de estudar o modo como este processo de
criação de ferramentas está acontecendo, propõe-se uma pesquisa de caráter
exploratório e construtivo, utilizando-se do método Design Science Research.
Design Science Research é um método de pesquisa voltado para a criação de artefatos
como uma maneira de operacionalizar prescrições para problemas específicos
(DRESCH; LACERDA; ANTUNES JR., 2015). Tal método envolve etapas de
desenvolvimento e avaliação dos artefatos, ferramentas funcionais que podem ser
27
validadas e estudadas visando explorar e gerar avanço no âmbito das teorias
(MARCH; SMITH, 1995).
O método abordado possibilita que o material resultante de uma pesquisa de caráter
prático gere discussões acerca da experiência, em termos de melhoria de um
ambiente ou cenário, buscando um vínculo teórico a partir da experiência
(HOLMSTRÖM; KETOKIVI; HAMERI, 2009). Após a resolução de casos específicos,
o pesquisador pode gerar conhecimentos que podem ser transferidos a domínios
similares, com base na reflexão sobre o aprendizado e análise dos casos, através da
generalização para uma classe de problemas (DRESCH; LACERDA; ANTUNES JR.,
2015; VAN AKEN, 2004).
Assim, no presente trabalho, busca-se emular o cenário do projetista programador,
por meio do desenvolvimento de instanciações do problema, na forma de
programação de plug-ins para uma plataforma BIM. Mecanismos para avaliação dos
plug-ins desenvolvidos foram então definidos por meio de técnicas abordadas na
bibliografia, e uma contribuição teórica acerca da experiência pode ser feita em
relação ao cenário apresentado neste capítulo introdutório, visando compreender o
fenômeno da criação de ferramentas de programação pelos próprios arquitetos e
engenheiros. Além disso, um artefato na forma de diretrizes ou guidelines pode ser
prescrito, de modo a elucidar o processo de desenvolvimento de ferramentas.
A classe de problemas, definida por meio de revisão bibliográfica (LACERDA et al.,
2013), é o “suporte à tomada de decisão”, presente nos projetos arquitetônicos como
uma diversidade de possíveis aspectos a serem interpretados e implementados na
forma de soluções projetuais. Como existem amplas oportunidades a serem
estudadas com programação na arquitetura, se fez necessário delimitar o tema
específico para o desenvolvimento dos plug-ins.
Para a delimitação, foi feito um survey preliminar ao início da pesquisa, envolvendo
profissionais usuários de ferramentas BIM, com conhecimento acerca de plug-ins ou
extensões de plataformas (SILVA et al., 2017a). O survey foi realizado com o intuito
de caracterizar o processo de projeto dos profissionais e identificar possíveis entraves
na adequação a normativas ou certificações, através da análise de integração de BIM
com aspectos específicos de performance das edificações, direcionando o
desenvolvimento dos plug-ins propostos.
A partir do survey, foi publicado um artigo em periódico internacional referente aos
resultados do estudo preliminar, que auxiliou na escolha do tema (SILVA et al.,
2017a). O artigo está disponível no Apêndice A, com as questões utilizadas no survey
no Apêndice B.
28
Conforme o direcionamento da experiência de delimitação do tema, foi definido
como instância para aplicação do método o desenvolvimento de plug-ins voltados
para o atendimento à Norma de Desempenho Brasileira.
A Norma de Desempenho das Edificações Habitacionais - NBR 15.575 (ABNT, 2013a,
2013b, 2013c, 2013d, 2013e, 2013f), em vigor desde 2013, representa grandes
mudanças em relação à tomada de decisões de projeto, pois introduziu uma gama de
novas necessidades tecnológicas, estabelecendo padrões mínimos que devem ser
atingidos por meio das escolhas de sistemas construtivos. Projetistas precisam se
adequar às novidades para especificar as soluções apropriadas, o que exige uma
organização de dados da edificação e uma consciência acerca dos processos
envolvidos na comprovação do desempenho.
Além disso, a Norma de Desempenho tem se tornado um assunto muito recorrente
na indústria da construção, aumentando ainda mais as exigências de projeto e
introduzindo complexidade nos processos. A dificuldade de se implementar estes
conceitos no processo de projeto é uma das motivações para direcionar os esforços na
abordagem BIM, cuja lógica processual alicerçada em dados ligados a modelos da
construção pode trazer a organização necessária para que uma edificação atenda aos
seus requisitos.
A escolha de programar ferramentas voltadas para a Norma de Desempenho foi feita
para compreender o processo de criação de ferramentas diretamente pelo
pesquisador, possibilitando explorar problemas específicos de projeto por meio de
codechecking e avaliar como tal abordagem pode ser viável em outras situações.
Assim, torna-se possível estruturar um arcabouço teórico sobre o cenário
inicialmente apresentado e, portanto, uma reflexão e contribuição acadêmica
alinhada com a metodologia proposta.
Em relação à plataforma e extensão VPL utilizadas para a programação,
respectivamente, foram escolhidos Autodesk Revit e Dynamo, devido à presença de
comunidades de usuários já estabelecidas, na forma de fórums e bancos de dados
virtuais, que permitem o contato com outros projetistas programadores, o que
possivelmente reforça o processo de emulação do cenário descrito de forma
adequada.
A partir das justificativas, o objetivo geral do presente trabalho é: compreender o
fenômeno do uso da programação pelo projetista do futuro por meio do
desenvolvimento de programação em um software BIM.
Para alcançar isto, três objetivos específicos são elencados: (1) prescrever
ferramentas como instanciações do problema principal, voltadas para o atendimento
29
da Norma de Desempenho em projetos; (2) avaliar a aplicabilidade das ferramentas
desenvolvidas; (3) explorar diretrizes para o desenvolvimento de programação e
possíveis situações onde ferramentas semelhantes às desenvolvidas poderiam ser
aplicadas.
A estrutura do trabalho está organizada com os capítulos seguintes (2, 3 e 4) focados
na revisão bibliográfica: Building Information Modeling; Programação em Softwares
BIM; e Performance das Edificações, de forma a apresentar conceitos fundamentais,
elucidar mais aprofundadamente nuances do cenário descrito e analisar alguns
trabalhos já desenvolvidos nestas temáticas.
Então, é apresentado o Capítulo 5 – Design Science Research, voltado para a
metodologia onde fundamentos e as etapas do método são descritos, visando
esclarecer o caminho tomado para a condução do trabalho.
As duas ferramentas de programação desenvolvidas para atendimento à Norma de
Desempenho são apresentadas no Capítulo 6 – Plug-ins Desenvolvidos, onde
soluções propostas em cada uma das instanciações (desempenho acústico e lumínico)
são apresentadas, bem como o projeto, fluxogramas e descrição das funcionalidades
de cada solução.
O Capítulo 7 – Avaliação dos Plug-ins aborda a construção de um mecanismo de
avaliação das ferramentas e uma aplicação inicial deste, como uma maneira de obter
feedback qualitativo acerca do uso das ferramentas desenvolvidas.
Por fim, no Capítulo 8 – Conclusão, são apresentadas contribuições teóricas através
de diretrizes para o desenvolvimento das ferramentas, reflexões acerca do que foi
compreendido na experiência, a generalização das instanciações para a classe de
problemas inicialmente descrita e considerações finais para estudos futuros.
30
2. BUILDING INFORMATION MODELING
A área de projetos do setor de Arquitetura, Engenharia e Construção (AEC) é
formada por uma diversidade de profissionais com diferentes especialidades:
arquitetura; estruturas; instalações e execução de obras. Durante o processo de
projeto tradicional, com o uso de softwares de desenho 2D de forma sequencial ao
longo dos processos de projeto, caracteriza-se a fragmentação das informações e o
isolamento das disciplinas pelas partes envolvidas. Nestas situações, a informação é
trocada por etapas entre os projetistas meramente por meio da documentação 2D de
projeto do empreendimento, o que abre espaço para diferentes interpretações,
consequentemente possibilitando que erros de projeto passem despercebidos ao
longo das etapas subsequentes (FERREIRA; SANTOS, 2007).
Segundo Ferreira e Santos (2007), o detalhamento tradicional de projetos alicerçado
na representação 2D não deveria ser a principal maneira de analisar e conceber
projetos, mas apenas uma forma de formalizar documentação. O modelo de projeto
tradicional carece de informações precisas devido ao uso de simbolismo, presença de
ambiguidades, soluções incompletas e omissão de dados importantes. Isto ocasiona
erros que podem se propagar ao longo do tempo, tornando-se visíveis apenas na
etapa de execução ou operação; falhas de projeto que geram custos adicionais e
prazos extrapolados, introduzindo variáveis não previstas, informações errôneas e
incontroláveis que podem comprometer a qualidade da edificação.
Esta situação, aliada à cultura artesanal de construção, fazem com que o cenário da
indústria da AEC, quando comparado a outros setores, tenha baixa eficiência de
gestão de recursos, complicações de coordenação entre projetistas e dificuldade na
implementação de inovações nas etapas de projeto. Circunstâncias nocivas para o
desenvolvimento do setor quando se vislumbra a crescente expectativa dos
consumidores e o aumento dos níveis de complexidade dos projetos de arquitetura
(EASTMAN et al., 2008). Tais problemas são oriundos, dentre outros aspectos, do
caráter documental do processo de projeto tradicional, onde há um esforço
considerável de tempo e aumento de custos para manutenção de informações
(FERREIRA; SANTOS, 2007).
Kumar (2015) ressalta que falhas no setor da construção civil podem ser classificadas
em 3 categorias: práticas fracas de organização e gerenciamento de projeto; objetivos
de projeto mal definidos ou inexistentes e; planejamento ineficiente de projeto. O
autor relata que estas causas são responsáveis por uma parcela expressiva de cerca
de 71% das falhas, todas relacionadas à ausência de informações de qualidade no
desenvolvimento do projeto.
31
Em tal cenário, a modelagem de processos torna-se uma maneira de entender e
controlar as atividades, de modo que haja estimativa de tempo, custo, prazo e
recursos durante as etapas projetuais. A identificação de necessidades, explicitação e
racionalização de processos, aliada à automatização de atividades e ao estímulo à
colaboração são práticas que visam melhorar a qualidade dos empreendimentos.
Em relação a trabalhos que abordam as potencialidades da implementação de BIM
no processo de projeto em detrimento à representação 2D, Li et al. (2014) apontam
benefícios que vão desde o levantamento automático de quantitativos, até a precisão
do planejamento, transparência de etapas, e melhoria na tomada de decisão. Os
autores enfatizam, em um estudo de caso, os esforços de retrabalho que foram
evitados por meio da transferência do modo de trabalho, de plantas 2D para uma
modelagem de informação tridimensional.
Frente a tais considerações, o Building Information Modeling é apontado como uma
alternativa aos processos tradicionais referidos, introduzindo melhorias na
representação por meio da tecnologia CAD 3D paramétrica – para remover
inconsistências oriundas do processo tradicional e documental; um maior controle
das informações de projeto nas etapas iniciais – de modo a prever e reduzir o
impacto das falhas; e potencializando a coordenação de disciplinas de projeto – de
modo a inserir a colaboração entre as partes interessadas conforme o avanço de
etapas de empreendimentos (EASTMAN et al., 2008).
Em relação à definição de BIM, Succar (2009) relata que o termo possui conotações
interligadas (Figura 1), relativas à: modelagem, formação, apresentação e/ou escopo
de um conjunto organizado de dados significativos e acionáveis; ligados a uma
edificação, estrutura, espaço fechado ou ambiente construído; com os objetivos de
construir virtualmente, estender as análises, explorar as possibilidades, estudar
cenários simulados, detectar colisões, calcular custos relacionados, avaliar
construtibilidade, planejar a demolição, administrar e manter.
Figura 1 - Definições sobre o termo BIM
Fonte: Traduzido e adaptado de Succar (2009).
32
Estes conceitos podem ser ilustrados em relação aos processos definidos como
tradicionais por meio da interpretação da curva de McLeamy (Figura 2). Conforme as
oportunidades e a capacidade de impactar custos de obra e performance diminuem
ao longo do ciclo de vida do produto, o custo de mudanças inesperadas relacionadas
às decisões de projeto aumenta. Por manter sua ênfase nas etapas iniciais – focando
no detalhamento e antecipação de problemas por meio de análises da modelagem, o
BIM busca trabalhar abaixo da curva (1), onde, nos processos de projeto aproveita-se
ao máximo as capacidades da modelagem para o estudo de alternativas, simulações e
planejamento, e não meramente para a geração de documentação (CBIC, 2016).
Figura 2 - Curva de McLeamy
Fonte: Adaptado de Fundamentos BIM (CBIC, 2016).
Há, contudo, uma ressalva: a curva de McLeamy não retrata as mudanças nos
processos advindas do BIM, e realiza uma comparação tomando como base as etapas
de processos baseados em documentação. Os processos com o uso de BIM mudaram,
com inclusão de novas etapas. Portanto, a curva representa uma aproximação, visto
que pode existir ainda a situação da ocorrência de partes dos dois workflows de
forma paralela e não excludentes.
Por outro lado, a implementação de uma lógica processual voltada para as fases
iniciais busca utilizar o próprio projeto como articulador do diálogo e da integração
entre projetistas, gerando feedback e fomentando o fluxo de informações nas etapas
projetuais futuras. Isto permite que as análises de custo e impacto das decisões
tomadas nas fases de projeto sejam dotadas de contextos ricos (EASTMAN et al.,
33
2008), para que possam ser utilizadas ativamente nas situações subsequentes de
execução e operação, dando suporte à atuação de outros profissionais envolvidos e
consolidando o processo integrado.
Quanto à abrangência do uso de BIM no ciclo de vida das edificações (Figura 3), o
potencial pode ser observado pela inclusão de novas dimensões de complexidade
nos processos, desde a vinculação de partes de um modelo em relação ao tempo para
execução de tarefas para construção (4D) até o custo incorporado nestes períodos,
por materiais e mão de obra (5D) (LI, 2016). Embora as dimensões BIM mais
conhecidas sejam 4D e 5D, alguns autores apontam para outros possíveis conceitos
onde se agregam camadas de informação nos modelos, gerando conceitos 6D, 7D, e
assim por diante (SANHUDO, 2016). Isto pode ocorrer quando são acrescidos
contextos como sustentabilidade e certificações (JALAEI; JRADE, 2014); gestão de
infraestrutura e manutenção (KENSEK, 2015); conforto e eficiência energética
(GERRISH et al., 2017); segurança (ZHANG et al., 2013), entre muitas outras, desde
que a informação possa ser aproveitada não apenas durante o desenvolvimento dos
projetos, mas também na fabricação de componentes, na execução e na operação.
Figura 3 - Ciclo de vida das edificações
Fonte: Adaptado de Advenser (2018).
Além disso, durante estas etapas, um dos destaques do BIM durante o
desenvolvimento dos projetos é a compatibilização e coordenação técnica de
disciplinas. Conforme Korman, Simonian e Speidel (2010), a interação entre
disciplinas de arquitetura, estrutura e sistemas prediais – MEP (Mechanical, Electrical
and Plumbing) pode antecipar muitos problemas de projeto antes que estes alcancem
a realização em obra e onde seu custo pode ser muito maior. Em tal cenário, o
34
potencial da modelagem tridimensional BIM antecipa processos construtivos
virtualmente por um modelo interconectado aos diferentes projetos, oferecendo
também opções de otimização em termos de posicionamento e desempenho de
elementos da modelagem (GOES, 2011).
Quanto à implementação de BIM na execução de empreendimentos, destaca-se o
trabalho de Biotto, Formoso, e Isatto (2015), que, ao utilizarem o software
Navisworks, demonstram as potencialidades da tecnologia por meio da
sincronização de cronogramas de obra com modelagens de informação (BIM 4D) em
estudos de caso. O estudo apresenta benefícios no processo de planejamento da
execução, antecipando não apenas conflitos espaciais, mas também logísticos, dando
suporte e rapidez na tomada de decisão e promovendo a coordenação do layout de
obra com abastecimento de materiais, ampliando a eficiência da sequência de
produção.
Contudo, para organizar todos estes conceitos, processos e evolução tecnológica em
um arcabouço teórico compreensível, Succar (2009) define conceitualmente BIM
como uma integração entre produtos e processos e não apenas o uso de tecnologias e
ferramentas. Em seu trabalho de destaque para a área, o autor divide este arcabouço
em três áreas: Campos, Estágios e Lentes.
Em relação aos Campos, Succar (2009) destaca 3 diferentes ambientes interligados
(Figura 4), porém, distintos conforme a função dos players envolvidos, seus produtos
e seus requisitos para que funcionem. São eles: Tecnologias, Políticas e Processos.
35
Figura 4 - Campos de atividade do BIM
Fonte: Succar (2009).
Em relação ao campo da Tecnologia, o autor se refere ao grupo de pessoas que
desenvolvem softwares e equipamentos voltados para aumentar a produtividade,
eficiência e rentabilidade de setores da construção. São as empresas de software
comercial e desenvolvedores, que tem como produto novas ferramentas e sistemas
que serão utilizadas pelo campo dos Processos.
O campo das Políticas está relacionado ao conjunto de pessoas voltadas para
preparar novos praticantes, desenvolver pesquisa em BIM e definir contratos e regras
no âmbito do uso de BIM. São os centros de pesquisa, instituições educacionais e
órgãos reguladores, tendo como produto a geração de conhecimento, boas práticas
ou novas normativas e regulamentações que direcionarão o campo dos Processos.
Quanto ao campo dos Processos, Succar (2009) cita o grupo de pessoas que projeta,
executa, utiliza, gerencia e mantém a construção através do uso dos produtos do
36
campo da Tecnologia, de acordo com as disposições do campo das Políticas. São os
engenheiros, arquitetos, construtores, clientes e outras partes interessadas, que têm
como produto a própria edificação.
Em relação à segunda dimensão conceitual proposta por Succar (2009), os Estágios de
Maturidade, mensura-se o avanço gradativo e sequencial da implementação de BIM
em organizações por meio da evolução de sua maneira de projetar. O autor descreve
este conceito através de 3 estágios do BIM (Figura 5), acrescidos por um estágio Pré-
BIM e o estágio Pós-BIM (também referido como IPD – Integrated Project Delivery, nD
Modeling, ou viDCO – virtually integrated Design, Construction and Operation
(SUCCAR et al., 2014)).
Figura 5 - Estágios de maturidade de projetos em BIM
Fonte: Succar (2009).
O Pré-BIM é caracterizado pelo processo de projeto tradicional descrito ao início
deste capítulo, onde a documentação 2D ainda é a principal maneira de expressar e
detalhar a edificação, apresentando fluxos de trabalho sequenciais e fragmentados,
com baixo ou inexistente nível de interoperabilidade entre disciplinas.
O Estágio BIM 1 é caracterizado pela Modelagem Baseada em Objetos, onde os
projetistas utilizam softwares BIM para modelar uma ou mais disciplinas (por
exemplo, modelo de arquitetura), visando, principalmente, automatizar a geração e
coordenação de documentação 2D e utilizar o modelo 3D para visualização. Neste
estágio, o processo colaborativo ainda é similar ao Pré-BIM, com poucas relações
entre modelos e pouca influência dos processos de projeto, relações contratuais e
comportamento organizacional existente (SUCCAR, 2009).
No Estágio BIM 2, surge a Colaboração Baseada em Modelos, onde os projetistas
ativamente buscam utilizar modelos BIM de diferentes disciplinas para dar suporte
37
uns aos outros e coordenar os processos. Nesta etapa, ocorre a integração de novas
camadas de complexidade do BIM como análises de prazo (4D) e estimativas de
custo ao longo do tempo do processo (5D). Além disso, Succar (2009) destaca que
ocorrem mudanças na maneira de contratar serviços e na cultura organizacional, que
se intensificam devido ao fluxo de trabalho e os novos produtos gerados, com foco na
criação de modelos em detrimento da geração de documentação.
O Estágio BIM 3 – Integração Baseada em Redes, é composto pela adoção de modelos
semanticamente ricos, com informações de múltiplos contextos, mantidos por meio
de uma colaboração que perdura durante todo o ciclo de vida da edificação. Novas
dimensões de análise são implementadas em etapas cada vez mais iniciais do
processo, cobrindo aspectos de projeto, execução e operação de forma simultânea,
incorporando também aspectos relacionados à sustentabilidade, custo do ciclo de
vida, lean construction, segurança, manutenção e outras. Segundo o autor, é necessária
uma profunda reformulação das relações contratuais, envolvendo ativamente
também outras partes interessadas no processo, como fabricantes e
regulamentadores.
O Estágio Pós-BIM é apresentado por Succar (2009) como uma visão de longo prazo
do amadurecimento dos processos, caracterizado por ser um amálgama dos campos
de Tecnologia, Processos e Políticas. Neste estágio, há a integração de pessoas,
sistemas, estruturas de negócio e melhores práticas, utilizando o potencial de todos
os participantes não apenas para projetar, mas para otimizar os resultados,
minimizar desperdícios e falhas nas etapas estabelecidas.
Para que as organizações atinjam maior maturidade e alcancem os Estágios BIM
avançados, os Campos BIM também devem se desenvolver – algo que ocorre
individualmente e de forma heterogênea. Para poder analisar este cenário nas
organizações, Succar (2009) descreve as Lentes, o terceiro componente de seu
arcabouço teórico. As Lentes servem como mecanismos para destacar ou filtrar certos
aspectos de um Campo ou Estágio BIM, em diferentes escalas de detalhamento, por
exemplo, atribuições de cada parte interessada em determinado processo, fluxos de
informações interorganizacionais, gerenciamento de processos intraorganizacionais e
competências necessárias para executar certas tarefas (SUCCAR; SHER; WILLIAMS,
2013). Isto permite que o observador – projetista ou pesquisador, identifique as
relações, competências e requisitos necessários para o aprimoramento em áreas
específicas, para que a implementação de BIM nos Campos de Tecnologia, Processos
e Políticas possa ser operacionalizada e maturada para avaliar e alcançar novos
Estágios. Um exemplo disso é a necessidade de avanços no Campo de Políticas (por
normas claras, políticas encorajadoras, pesquisas inovadoras, padronizações) e nas
38
Tecnologias (por softwares avançados, de alta interoperabilidade, com funções
robustas), para que o Campo de Processos (um escritório de arquitetura e
engenharia) possa atingir um novo nível de colaboração e a inclusão de novas
análises da edificação em seus processos.
Além dos tópicos levantados e do arcabouço teórico apresentado, para elucidar
algumas nuances da temática, se faz necessário o aprofundamento em características
e premissas específicas do processo BIM. Eastman et al. (2008) ressaltam três pilares
conceituais do BIM: (1) design paramétrico ou parametrização; (2) interoperabilidade
e (3) colaboração.
2.1 Parametrização
No contexto de softwares BIM, Eastman et al. (2008) definem a necessidade de
parametrização de dados como maneira de manter a consistência e relevância das
informações da modelagem em pranchas de desenho. No processo de projeto
tradicional as informações das edificações são focadas em linhas avulsas e
desconexas, enquanto isso, no processo BIM obrigatoriamente é necessário a prática
de projeto em 3D, por meio da modelagem de objetos paramétricos interligados,
inteligentes e inseridos em contextos lógicos de informação – uma abordagem
centrada no modelo.
Embora o propósito mais aparente de modelos virtuais seja a visualização das
características geométricas, Eastman defendeu, em 1981, em um de seus primeiros
trabalhos, que um dos aspectos não explorados seria compreender as propriedades
dos elementos de uma edificação por meio de atributos e especificações – parâmetros
que definem e categorizam seu papel no projeto, não só para racionalizar a escolha
de materiais, mas também para garantir que sejam construíveis – uma proposta de
modelo interativo (EASTMAN, 1981).
Papamichael et al. (1996) descreveram algo semelhante ao proposto por Eastman
(1981) em relação à representação de componentes de uma edificação – objetos
(paredes, esquadrias, pisos, forros) que possuem parâmetros (transmitância,
refletância, etc.) organizados em relações com outros objetos (regras semânticas). Os
autores defendem que esta abordagem de representação orientada a objetos permite,
além da flexibilização da criação dos modelos, abarcar informações através de
múltiplos softwares, apresentando informações consistentes, que podem ser
acionadas e modificadas por estes para outros contextos além da consistência
geométrica (PAPAMICHAEL et al., 1996).
39
Eastman (1981) também criticou o sistema automatizado de projetos 2D da época por
não serem dotados de informações interconectadas, ressaltando que conjuntos de
linhas organizadas em uma planta baixa por si só não formam uma parede, mas um
conjunto de elementos virtuais, de camadas sólidas, com informações acerca de seu
comportamento, materiais e dimensões, aliada à integridade semântica e consistência
em relação às esquadrias e outras paredes, pode remeter a um componente de parede
(EASTMAN, 1981). Além disso, o autor ressalta que o sistema de projeto
automatizado (desenho 2D) não foi inicialmente concebido para ser interativo, visto
que a quantidade de retrabalho e reorganização de informações necessárias a serem
feitas quando há uma mudança de projeto são vastas.
No processo de projeto, o autor defendia que o projetista precisaria ter controle total
acerca das relações semânticas em elementos, desde o rigor das dimensões e
características até o desenvolvimento de mecanismos que atualizam as informações
geométricas e não geométricas em todas as instâncias e vistas de um modelo quando
uma mudança é feita, tornando o processo de projeto fluído e dotado de flexibilidade
(EASTMAN, 1981).
Anos depois, no BIM Handbook (EASTMAN et al., 2008) tais conceitos são
reapresentados com a evolução da computação, desde o refinamento de modelos, da
maneira como a parametrização foi sendo inserida no design computacional, os
graus de complexidade e detalhamento dos modelos, até a concretização dos
conceitos do BIM.
Nos dias de hoje, estas definições podem ser facilmente percebidas por meio da
exploração da modelagem de elementos em um software BIM para arquitetura. Na
Figura 6, é possível perceber que uma simples porta contém uma diversidade de
informações necessárias para ser efetivamente interpretada no software, e não apenas
representada por linhas, como ocorre nos softwares de desenho 2D. São apresentadas
desde dimensões de espessuras dos componentes, até tipos de materiais, distâncias
de espaçamentos e linhas de referência, que permitem vincular o elemento de porta a
um Host – neste caso, uma parede, adaptando inclusive, a largura dos batentes
conforme a espessura da parede de forma automática.
40
Figura 6 - Modelo de porta e seus parâmetros no ambiente de edição de famílias do Revit
Fonte: Autor (2018).
As relações semânticas também podem ser observadas a partir da consistência dos
dados advinda da interação entre elementos BIM. Na Figura 7, foi modelado um
elemento de parede por camadas no software Revit, que automaticamente calculou
os parâmetros de área e volume da camada de alvenaria. Então, foi adicionado um
elemento de porta, que detecta que a parede é um Host e, portanto, ao ser
posicionada, subtrai a área e volume de sua abertura da área e volume da parede, de
forma automática. Em um terceiro momento, foram adicionados um pilar e uma viga
e, por meio dos comandos Trim e Cut, é possível observar que novamente, a área e
volume da parede de alvenaria são reduzidos. Esta abordagem permite uma clareza
muito maior tanto na geração de documentação, como na precisão dos quantitativos,
uma vez que a consistência das informações está atrelada à qualidade ou nível de
desenvolvimento da modelagem.
Figura 7 – Consistência dos parâmetros de área e volume de uma parede com elementos vinculados
Fonte: Autor (2018).
41
Em relação ao nível de desenvolvimento, segundo Eastman et al. (2008), é algo que
está diretamente relacionado à necessidade de informações em determinado
momento em um projeto. O LOD (Level of Development) é estabelecido como a
correlação entre o modelo e o estágio de desenvolvimento do produto, definindo que
características e que tipo de informação um modelo BIM de uma edificação precisa
ter em seus diferentes estágios, permitindo que o modelo seja utilizado para cada vez
mais finalidades (BIMFORUM, 2017). O LOD pode partir de representações mais
genéricas, com o uso de modelos de massa, até modelos para produção,
detalhamento e projeto as built (Figura 8).
Figura 8 - Diferentes LOD de modelos BIM
Fonte: BIMetica (2018).
Com estas propriedades, as decisões de projeto podem ser feitas em quase qualquer
ordem, controladas pelas relações de integridade semântica no modelo, com efeitos
de tais decisões propagados para as etapas subsequentes de projeto, podendo ser
retroagidas e suas consequências reavaliadas (EASTMAN et al., 2008). As
plataformas BIM são capazes de gerar plantas, fachadas e detalhamentos da
edificação com precisão e clareza, o que, quando aliado ao levantamento de
quantitativos automático, pode agilizar muito o processo de projeto na medida em
que reduz erros e retrabalho oriundos do processo de desenho 2D (AUTODESK,
2017a).
2.2 Interoperabilidade
A segunda característica da tecnologia BIM apresentada por Eastman et al. (2008) – a
interoperabilidade – está ligada à capacidade de conversão e comunicação dos
modelos de informação entre as diferentes plataformas de forma transparente e com
manutenção de dados, com o objetivo de facilitar e automatizar processos na medida
em que elimina a necessidade de copiar manualmente informações de um software
para uso em outro.
Utilizar tabelas, croquis, esboços ou calculadoras externalizadas ao modelo de
informação torna-se impraticável conforme o nível de complexidade dos projetos
42
cresce. Quando se considera o modelo interativo proposto por Eastman (1981),
colocar tais informações em um ambiente virtual intercomunicável torna-se
imprescindível para a flexibilidade do projeto e a colaboração entre as partes
interessadas.
É natural que um projeto passe por diferentes softwares no processo BIM e, ao passo
em que mais softwares BIM são desenvolvidos, se faz necessário tornar o intercâmbio
de informações mais consistente por meio de padrões, o que gera um desafio para a
interoperabilidade, principalmente de plataforma para plataforma (EASTMAN et al.,
2008). Um exemplo disto são modelos de arquitetura desenvolvidos no Revit e
abertos em outro software como Archicad ou Bentley, que necessitam manter
intactos muitos dos atributos originais.
Neste cenário, surgem duas variáveis importantes: as ferramentas complementares,
na forma de plug-ins, extensões, e softwares utilitátios; e a padronização por meio de
formatos abertos. Em relação aos softwares complementares, um exemplo é
apresentado na Figura 9, onde é demonstrado um fluxo de interoperabilidade por
meio do plug-in Scia (NEMETSCHEK, 2018), que importa um modelo do software
Revit, possibilitando análise estrutural e dimensionamento de elementos de aço.
Então, o modelo atualizado com pilares, vigas e outros elementos ajustados conforme
o cálculo é exportado de volta ao Revit, permitindo a continuidade do fluxo de
trabalho com menor perda de informações. O tópico dos plugins voltará a ser
abordado pela perspectiva da programação no próximo capítulo deste trabalho.
Figura 9 - Ciclo de interoperabilidade entre arquitetura e estrutura
Fonte: Nemetschek (2018).
43
Em relação à padronização por formatos abertos, um esforço recorrente está sendo
feito pela buildingSMART, anteriormente chamada de IAI (International Alliance for
Interoperability), instituição composta por um consórcio de empresas norte-
americanas. A buildingSMART busca, através de formatos de modelagem
padronizados e abertos – IFC, IFD, IDM, entre outros, integrar a coordenação e
gerenciamento de informações entre os vários softwares BIM presentes no mercado,
de modo a amplificar a qualidade, comunicação e produtividade de projetos BIM
(BUILDINGSMART, 2017). A premissa destes formatos é de que grandes plataformas
possam, opcionalmente, converter a geometria e os dados do modelo BIM
livremente, para que deixem de ser exclusivos às especificidades de apenas um
software ou rede de softwares de uma empresa, permitindo maiores chances de
colaboração.
O IFC – Industry Foundation Classes, formato atualmente mais avançado de
interoperabilidade BIM, é responsável por tratar as informações por meio de um
modelo de dados orientado a objetos. O IFD é um formato similar, porém, orientado
às bibliotecas de componentes. Por fim, o IDM determina quais informações são
relevantes para cada projetista que deseja acessar a modelagem por meio de
hierarquias e permissões. (BUILDINGSMART, 2017)
Em relação à padronização por meio de normas voltadas para o BIM no Brasil,
atualmente, duas normas técnicas apresentam um esforço para inserção da
modelagem de informação no contexto padronizado: NBR ISO 12006-2 – Construção
de edificação – Organização de informação da construção (ABNT, 2010) e NBR 15965
– Sistema de classificação da informação da construção (ABNT, 2011). Tais esforços
são importantes para criar condições de aplicação e de criação de tecnologias
voltadas ao setor de produção de projetos, bem como para auxiliar na influência
brasileira acerca de interoperabilidade e assuntos internacionais do processo BIM.
Outro esforço voltado para regular BIM no Brasil foi o Decreto de 5 de junho de 2017
(BRASIL, 2017), documento federal que instituiu o Comitê de Implementação do
Building Information Modeling, de caráter temporário, voltado para a disseminação do
BIM. Após a criação do comitê, este decreto foi revogado pelo Decreto nº 9377 de 17
de maio de 2018 (BRASIL, 2018), que instituiu a Estratégia BIM BR – Estratégia
Nacional de Disseminação do Building Information Modeling no Brasil, visando
propiciar o investimento em BIM no país. Dentre alguns dos objetivos do decreto
estão a coordenação do setor público para adoção do BIM; propor atos normativos
para estabelecer compras e contratações públicas com o uso de BIM; desenvolver
normas técnicas, guias e protocolos; e incentivo à concorrência no mercado por meio
de padrões neutros de interoperabilidade.
44
2.3 Colaboração
Por fim, a terceira característica apontada por Eastman et al. (2008) está ligada ao
processo colaborativo de projeto, focado na presença do gerente ou coordenador do
modelo, profissional encarregado das regras de comunicação entre projetistas BIM,
da definição de padrões de informação, checagem de interferências e
compatibilização de modelagens. Tais atribuições e cenários de coordenação de
projetos são explicitados também por Garbini e Brandão (2014), que definem os
coordenadores como um ou mais profissionais que, além das atribuições citadas,
planejam e implantam a tecnologia BIM.
Como destacado anteriormente, por projetar ser uma atividade multidisciplinar,
informações de diversas instâncias podem estar inseridas nos componentes do
modelo e apresentadas conforme as especialidades de diferentes projetistas – por
exemplo: um revestimento cerâmico que contém informações relativas a
propriedades estéticas, acabamento e brilho para o profissional de interiores; peso e
espessura do sistema de revestimento para cálculo de carregamento para o
profissional de estruturas; custos e produtividade de serviço para o profissional de
gerenciamento de obras; características térmicas, de acústica e refletividade para o
profissional de análise de performances e assim por diante.
Isto implica em definir a hierarquia de relações do modelo e as permissões dadas a
cada projetista na manipulação do mesmo: mudanças geométricas no projeto
arquitetônico impactarão mudanças no lançamento e dimensionamento da estrutura
e posicionamento de sistemas prediais, fazendo com que informações de diversos
profissionais necessitem estar consistentes e atualizadas em seus modelos
(EASTMAN et al., 2008). Devido ao fato de que as informações não geométricas são
relacionadas aos parâmetros inerentes dos elementos BIM, como custos e materiais
empregados, alterações nestes valores também modificarão outros aspectos de
projeto, como orçamento e análises do comportamento da edificação por simulações,
portanto, também pode impactar as decisões dos envolvidos.
Em meio a esta riqueza de informações em diferentes contextos, cada vez mais se
intensifica a necessidade da coordenação técnica de projetos, que pode ser dada por
meio do Coordenador de Projetos, profissional que busca o aumento da troca de
informações entre projetistas, com atribuição de direcionar fatores técnicos como
escopo, tempo, integração, qualidade, comunicação e custos na equipe de projeto
(GARBINI; BRANDÃO, 2014). O objetivo principal da coordenação é a transparência
de comunicação entre membros de um projeto, buscando, por meio da integração de
especialidades (Figura 10), produzir soluções ou atender padrões de qualidade
(GARBINI; BRANDÃO, 2014; TZORTZOPOULOS, 1999).
45
Figura 10 - Colaboração entre partes interessadas no processo tradicional e BIM
Fonte: Adaptado de BibLus-Net (2018).
Desta forma, a adoção da tecnologia BIM em seus diferentes níveis permite agregar
um maior grau de qualidade e transparência nos projetos de edificações. Assim,
pode-se desafiar as culturas já estabelecidas em escritórios e empresas construtoras,
pois insere-se efetivamente conceitos de cooperação, interdependência e integração
no campo dos processos, o que permite uma evolução gradativa nos estágios de
maturidade (SUCCAR; SHER; WILLIAMS, 2013).
Uma das maneiras de trabalhar colaborativamente é através de um modelo federado,
composto por modelos de arquitetura, estruturas, instalações prediais e outras
disciplinas (EASTMAN et al., 2008). O modelo de tais informações compartilhadas
possibilita aos projetistas de cada área contribuir aditivamente nos processos de
tomada de decisão, cientes das particularidades dos outros. Nestas situações,
softwares de visualização e ferramentas de detecção de interferências como a opção
Clash Detection (AUTODESK, 2017a) possibilitam prever possíveis problemas nos
modelos, gerando um feedback visual quando ocorre um conflito entre duas
disciplinas, que pode ser transmitido à equipe para adequação.
Para exemplificar isto, na Figura 11, são apresentados resultados de um dos trabalhos
realizados pelo autor (SILVA et al., 2017b), mostrando o uso da opção Clash Detection
no software Navisworks. Foram cruzadas as informações entre elementos estruturais
e de sistemas prediais, o que permite encontrar, por exemplo, elementos de calhas e
tubulações em conflito com pilares na horizontal (A, B); viga ocupando espaço
46
destinado ao reservatório (C); diversas tubulações de água atravessando vigas (D); e
tubulação atravessando pilar na vertical (E).
Figura 11 - Detecção de interferências entre elementos estruturais e de sistemas prediais
Fonte: Silva et al. (2017b).
47
3. PROGRAMAÇÃO VISUAL EM SOFTWARES BIM
Este capítulo é dedicado à fundamentação de alguns conceitos da programação na
tecnologia BIM. Caracteriza-se pelo uso de aplicações externas às plataformas
principais, ferramentas conhecidas como plug-ins e extensões, que utilizam a própria
programação do software BIM para manipular diferentes funções do ambiente de
projeto, possuindo propósitos definidos e focados em adicionar versatilidade a
comandos já existentes. Profissionais que utilizam BIM podem utilizar plug-ins para
atingir metas particulares durante seus processos de projeto, bem como para
aumentar sua produtividade, deixando com que as aplicações executem tarefas
repetitivas e braçais, ou para que realizem cálculos e comandos em sequência por
meio de rotinas de programação, entre outros usos.
O potencial de customizar um software já existente para necessidades específicas de
projeto está na maior quantidade de alternativas acrescidas e no intuito de superar
limites inerentes da plataforma (AISH, 2013a). Dentre as possibilidades adicionadas
pelo uso de ferramentas externas está a integração e compartilhamento de
informações de modelos BIM entre softwares. Tais ferramentas visam facilitar e
subsidiar a interação dos modelos, dando suporte também ao gerenciamento de
projetos e encorajando o desenvolvimento holístico (RUSCHEL et al., 2013).
Conforme Whitehead (2003), a customização de softwares na forma de utilidades tem
um papel importante no projeto, na medida em que possibilita interagir com as
funções por trás das interfaces de sistemas CAD, gerando projetos programáveis e
adaptáveis.
Neste contexto, Janssen (2015) destaca que o potencial das ferramentas de
programação pode ser ampliado quando estão em processos BIM ao invés da simples
modelagem 3D, devido às oportunidades de uso das informações além da geometria.
Alguns autores reforçam este argumento (FERREIRA; LEITÃO, 2015; KHAJA; SEO;
MCARTHUR, 2016; SEGHIER et al., 2017) e destacam que, embora seja útil para
desenvolver geometrias complexas na arquitetura, o verdadeiro papel da
programação no BIM está na transferência de informações não geométricas, por meio
do gerenciamento de regras e listas de dados. A programação de softwares BIM
deixa de manipular apenas a forma e passa a gerenciar dados dotados de contextos
interligados de maneira mais ampla (FERREIRA; LEITÃO, 2015).
Em relação a alguns trabalhos nesta temática, Khaja, Seo e McArthur (2016)
desenvolveram um estudo voltado para o processamento de informações de bancos
de dados em softwares como o Excel, e avaliaram o potencial da ferramenta para
48
transferir levantamentos das planilhas para o modelo BIM, automatizando processos
de preenchimento de parâmetros ou pareamento de informações.
Li (2016) demonstra através da programação, por meio de plug-ins de
interoperabilidade das plataformas Revit e Navisworks, uma possibilidade de
integração de dados de custo e prazo para avaliação e planejamento da construção
nas etapas iniciais de projeto. No trabalho, o autor desenvolve um modelo de
correlação de bancos de dados, automatizando o processo de estimativas e
possibilitando inserção de novas perspectivas de gerenciamento e tomada de decisão
de forma precoce no processo de projeto.
Singh, Sawhney e Borrmann (2017) realizaram um trabalho mostrando o potencial do
uso da programação para a redução de inconsistências na modelagem e do tempo de
desenvolvimento de projetos por meio de regras programadas. Os autores pontuam
que o uso da ferramenta faz com que os projetistas envolvidos dediquem mais tempo
na compreensão do funcionamento de seu modelo, nas relações matemáticas
envolvidas e nas propriedades dos elementos, tornando a manipulação do modelo
melhor orientada às informações realmente necessárias, em detrimento de atividades
que não agreguem valor.
Em relação ao desenvolvimento de ferramentas, Ottchen (2009) destaca a
importância da interoperabilidade, e relata que esta deve ser o foco nas ferramentas
projetuais, de modo que as informações do modelo possam expandir as possíveis
escolhas de um projeto e não limitá-las a especificidades de plataforma ou projetos
únicos. Nesta linha de pensamento, segundo Mackey e Roudsari (2018), um dos
grandes problemas do uso de plataformas é a integração entre diferentes softwares e
a necessidade de soluções específicas para situações únicas de projeto:
“oportunidades perdidas são um resultado direto do nosso pensamento de projeto
formado por ferramentas pouco integradas” (tradução nossa, MACKEY; ROUDSARI,
2018, p. 101). Neste sentido, esforços estão sendo feitos para aumentar a
interoperabilidade entre as linguagens de programação textual nos programas CAD,
como o software Rosetta, que permite que um código seja interoperável em
diferentes plataformas (FERREIRA; LEITÃO, 2015).
Contudo, conforme pontuado na introdução, as extensões de VPL também
possibilitam a criação de pontes de interoperabilidade entre softwares, ao mesmo
tempo em que tornam o processo de desenvolvimento de programação algo
interativo, de fácil aprendizado e acessível a usuários com pouco conhecimento
acerca de TPL (Textual Programming Languages), levando em conta a
interoperabilidade e a interdisciplinaridade necessária nos processos (SEGHIER et
al., 2017). A transição gradual e complementação do VPL pelo TPL também pode ser
49
feita por meio dos componentes híbridos (AISH, 2013b), conforme será discutido
mais adiante neste capítulo. A seguir, algumas extensões ou plug-ins de
programação visual vinculados a softwares BIM são apresentadas:
GenerativeComponents, Grasshopper, Dynamo e Marionette (BENTLEY, 2018;
DYNAMO, 2018b; GRASSHOPPER, 2018; VECTORWORKS, 2018).
A ferramenta de programação visual mais antiga é o GenerativeComponents para o
software AECOsim, da Bentley Systems (BENTLEY, 2018). No passado, seu
paradigma de programação não era atrelado à uma interface visual, adotando uma
visão simbólica ao invés dos nodes e wires. A extensão, atualmente, permite o controle
de objetos paramétricos por meio de programação de rotinas, com o foco na
exploração de diferentes alternativas de forma ágil e a integração com a plataforma
para facilitar processos de simulação, projeto e fabricação de produtos a partir de
funções básicas do AECOsim. Na Figura 12, é possível notar que a ferramenta opera
com interfaces de visualização da forma e de controle das rotinas de programação
simultaneamente, o que permite o feedback instantâneo das alterações em parâmetros.
Figura 12 - Progamação de elementos no Generative Components
Fonte: Bentley (2018).
Uma das principais ferramentas de programação visual do mercado é o Grasshopper,
que possui seu funcionamento atrelado ao software de modelagem Rhinoceros 3D,
da McNeel & Associates na forma de um plug-in de edição de algoritmos
(GRASSHOPPER, 2018; RHINO3D, 2018). Rhinoceros pode ser potencializado com o
Grasshopper para geração de formas de alta complexidade, design generativo e
evolutivo, fabricação digital, e diversas outras aplicações nas áreas de análise de
eficiência energética e sustentabilidade em edificações (ROUDSARI et al., 2013).
Recentemente, foi integrado a um software BIM por meio de sua conexão com o
50
ArchiCAD (GRAPHISOFT, 2017; SEGHIER et al., 2017), o que permite estender as
funções já conhecidas e difundidas efetivamente para dentro de processos BIM. Na
Figura 13, é mostrada a tela de programação – com os componentes (nodes e wires)
que guiam os dados através de um fluxo e compõe a rotina; a tela do Rhinoceros 3D –
com o modelo resultante programado; e a tela de modelagem do ArchiCAD – onde
as formas criadas foram importadas para dentro do contexto BIM.
Figura 13 - Importando geometria programada como elementos BIM no Archicad
Fonte: Graphisoft (2017).
Outra extensão de VPL inserida em um software BIM é o Dynamo para Autodesk
Revit, que possui funcionamento muito semelhante ao plug-in Grasshopper
(DYNAMO, 2018a), com uma interface de programação visual (onde os nodes são
criados e conectados) e interface de vista 3D (background onde o resultado das
operações programadas é representado). Por meio da interface de programação,
relações entre variáveis paramétricas são formadas para criação dos algoritmos ou
rotinas, possibilitando a exploração de propriedades de modelos conectados
diretamente ao software BIM e potencializando o uso de parâmetros ligados aos
componentes (DYNAMO, 2018a). Na Figura 14, verifica-se um exemplo de criação de
um componente de pilar para Revit por meio da parametrização completa de suas
dimensões, com a tela de organização de rotinas à esquerda, a forma resultante ao
centro, e sua inserção como elemento BIM no ambiente do Revit à direita. Devido ao
fato de que o Dynamo foi a ferramenta escolhida para o desenvolvimento da pequisa,
seu comportamento e funcionalidades serão aprofundados mais adiante neste
capítulo.
51
Figura 14 - Parametrização de um elemento de pilar no Dynamo e sua visualização no Revit
Fonte: Dynamo Gallery (DYNAMO, 2018a).
O Marionette (Figura 15) é mais uma alternativa de VPL, que opera na plataforma
BIM Vectorworks. Segundo os desenvolvedores, permite orquestrar e ditar projetos
de formas e customizações dentro do Vectorworks sem necessitar conhecimentos
profundos de programação (VECTORWORKS, 2018).
Figura 15 – Operações em painél com programação no Marionette
Fonte: adaptado de Vectorworks (2018).
Um aspecto interessante e em comum nas quatro ferramentas é a presença de
comunidades ativas de usuário que produzem, avaliam e submetem conteúdo, na
forma de rotinas, pacotes de novas funções, projetos, coleções de imagens de
destaque, ou discussões acerca da programação visual e seu potencial para
exploração do design. Algumas destas comunidades são o Food4Rhino
(FOOD4RHINO, 2018); fórum DynamoBIM (DYNAMO, 2018b); a seção User Projects
52
do GenerativeComponents (BENTLEY, 2018); e o Marionette Training Center
(VECTORWORKS, 2018).
Após a apresentação das ferramentas de forma geral, nas seções seguintes deste
capítulo é abordada a ferramenta de programação visual utilizada para a pesquisa: a
extensão Dynamo para Revit, com a descrição de seu funcionamento, bem como
alguns dos principais pacotes de programação utilizados.
3.1 Dynamo
Dynamo é uma ferramenta de programação que permite ao usuário visualizar o
comportamento de seus scripts, constituindo-se em um ambiente de VPL ligado à
plataforma Revit, que possibilita ao usuário extrair e administrar fluxos de
informação paramétrica por meio de nodes e wires que constituem rotinas
(DYNAMO, 2018c). Por ser baseado em uma VPL, Dynamo não exige conhecimentos
típicos de linguagens de programação textual para funcionar, o que flexibiliza a
criação de ferramentas para Revit por projetistas com certa facilidade.
A plataforma também permite manipular funções de quaisquer plataformas da
Autodesk que possuam um API (Application Programming Interface), o que permite
estender a programação para outros estágios do BIM com o uso de recursos dos
outros programas. Apesar de estar ligado a uma plataforma comercial, o código fonte
da ferramenta é aberto e seu desenvolvimento pode ser acompanhado no Git-hub
(GITHUB, 2018a), onde usuários desenvolvedores estendem as funcionalidades
existentes do Dynamo e apresentam documentação acerca das novidades.
Além do GitHub, existem diversas comunidades e fórums de usuários de Dynamo
que, além de auxiliar novos usuários no aprendizado da ferramenta, produzem
novas funcionalidades para a extensão na forma de Custom Nodes e Packages
(DYNAMO, 2018b; DYNAMONODES, 2017). São pacotes de funções que podem ser
livremente implementadas em rotinas para amplificar suas potencialidades. Tais
funções adicionais podem ser baixadas diretamente pela interface do Dynamo, por
meio dos menus “Packages” e então “Search for a Package” ou “Manage Packages”, o que
possibilita verificar atualizações nas composições facilmente. Seu funcionamento será
discutido mais adiante.
Em relação ao seu acesso no Revit, Dynamo está localizado na aba “Manage” (Figura
16), sendo disponível atualmente para as versões Revit 2016, 2017, 2018 e 2019. Além
disto, possui uma versão standalone, que opera sem ser necessário abrir o Revit,
porém, com muitas limitações acerca de funções utilizáveis; e a versão Dynamo
53
Studio, que além das funções originais, possui acesso a serviços na nuvem e sistemas
mais avançados para geometria (DYNAMO, 2018a).
Figura 16 - Localização do Dynamo na interface do Revit
Fonte: Autor (2018).
O funcionamento do fluxo de informações no Dynamo depende dos Nodes, objetos de
programação visual que performam operações únicas, como realizar um cálculo,
processar informação, selecionar ou consultar um elemento BIM, entre muitos outros.
A anatomia de um node é apresentada na Figura 17, onde é destacado o nome do node
(1) – para identificação; seu corpo (2) – que representa seu estado de atividade atual;
suas portas de input e output (3) – para inserção de informações e seus resultados; o
ícone de Lacing (4) – que controla a maneira como listas são interpretadas; e a opção
Default Value (5) – que permite algumas pré-configurações (DYNAMO, 2018a). O node
apresentado na figura, por exemplo, possui o nome Point.ByCoordinates, e necessita
de 3 valores de coordenadas (inputs) para criar um ponto no espaço tridimensional
(output).
Figura 17 - Anatomia básica de um nodo
Fonte: Dynamo Primer (DYNAMO, 2018c).
As informações dos nodes precisam ser ligadas em um fluxo de informação, o que é
feito pelos wires, conexões de dados que levam os outputs para nodes subsequentes,
tornando-se novos inputs. Na Figura 18, um node de criação de ponto por
54
coordenadas e um Integer Slider permitirá a criação de uma geometria de círculo
parametrizada pelo raio.
Figura 18 - Funcionamento de wires ligando informações aos nodes
Fonte: Autor (2018).
Utilizando uma configuração lógica organizada de funcionalidades de nodes, é
possível programar rotinas completas, também conhecidas como workflows ou graphs,
utilizando operações booleanas, com números inteiros ou reais, e palavras. Estas
rotinas naturalmente também precisam de inputs oriundos de elementos do projeto
BIM sendo manipulado e, para isso, Dynamo conta com uma vasta biblioteca de
nodos voltados para a seleção de elementos, categorias de materiais e famílias, entre
outros. Além disso, estes inputs podem utilizar não somente as geometrias e
parâmetros dos elementos BIM, mas também funcionalidades oriundas do próprio
Revit – vistas de projeto, filtros de visibilidade, tabelas de schedules, quantitativos
levantados, entre outros, possibilitando diversos pontos de partida para criação das
rotinas. Alguns nodes que capturam informações do modelo ou de configurações do
Revit são apresentados na Figura 19.
55
Figura 19 – Exemplos de inputs possíveis na interface do Dynamo
Fonte: adaptado de Dynamo Primer (DYNAMO, 2018c).
Assim, o controle das informações do modelo torna-se facilmente acessível pelo
usuário programador. No exemplo da Figura 20, um elemento de parede do Revit é
consultado, com sua geometria e parâmetros expostos pelos nodes Element.Geometry e
Element.Parameters. Nesta situação, a geometria e os dados internos da parede podem
subsequentemente ser utilizados em operações seguintes.
Figura 20 - Importando informações de parâmetros de uma parede do Revit
Fonte: Autor (2018).
56
Uma das maneiras de manipular informação dentro do Dynamo é por meio de listas,
que permitem que uma série de interações seja computada simultaneamente, regrada
pelo Lacing imposto no node – permitindo que listas com quantidades diferentes de
componentes sejam tratadas adequadamente. Na Figura 21, algumas operações com
sequências e multiplicação são demonstradas, assim como seus resultados na forma
de listas, visualizadas pelos nodes do tipo Watch. As listas podem então fornecer
informações de inputs de diversas naturezas – elementos, números, palavras e muitos
outros, de forma seletiva e precisa.
Figura 21 - Funcionamento de sequências, listas e operações matemáticas
Fonte: Sanhudo (2016).
Outra maneira de manipular as informações nas rotinas é por meio de
condicionantes lógicos, que permitem verificar a informação conforme uma regra
antes que esta prossiga no fluxo. Na Figura 22, três maneiras simples de realizar uma
verificação são apresentadas: por meio de um node If vinculado a uma operação
booleana; por meio do node “Formula”, onde uma equação é verificada; e por meio de
um Code Block com programação textual, emitindo uma resposta customizada com
concatenação de palavras.
57
Figura 22 - Funcionamento de condicionantes lógicos por 3 maneiras: node If, fórmula, e Code Block
Fonte: Autor (2018).
O Code Block apresentado no terceiro exemplo da Figura 22 consta no uso de
DesignScript para executar uma operação que também pode ser realizada apenas com
nodes comuns. DesignScript é a linguagem de programação textual presente
internamente nos nodes do Dynamo e em outros softwares que operam VPL voltados
para arquitetura e engenharia (AISH, 2013b). Conforme também ressaltado no
capítulo introdutório, um dos problemas da programação visual é a escalabilidade:
problemas relacionados à manutenção de programas em VPL quando aumenta-se a
complexidade e a extensão da rotina, o que dificulta e torna trabalhoso o
desenvolvimento ao longo do tempo (LEITÃO; SANTOS; LOPES, 2012).
O Code Block contendo DesignScript constitui-se em um elemento híbrido e, portanto,
uma possível solução para o problema de escalabilidade, pois permite que a
programação visual seja complementada, gradativamente, pela programação textual,
dotada de concisão e recursos mais arrojados (LEITÃO; SANTOS; LOPES, 2012),
permitindo, por exemplo, substituir vários nodes de VPL por apenas um de TPL.
Uma forma de realizar este processo de transição do visual para o textual é através
da opção “Node to Code” no Dynamo, o que faz com que um grupo de nodes
selecionados seja convertido em um Code Block de DesignScript, possivelmente
reduzindo o tamanho da rotina e, portanto, facilitando sua manutenção enquanto
conserva as funcionalidades originais. Na Figura 23, é apresentado um código em
VPL para criação de geometrias, composto por 5 nodes que se transformam em
apenas um, contendo 5 linhas de programação que interpretam os inputs exatamente
da mesma forma.
58
Figura 23 - Convertendo de visual para DesignScript textual
Fonte: adaptado de Dynamo Primer (DYNAMO, 2018c).
Outra maneira de simplificar ou compactar uma rotina é através de um Custom Node,
um node editável composto por vários outros que, quando aberto, apresenta o
ambiente de edição de nodes do Dynamo, que por sua vez permite a modificação de
inputs e outputs, bem como a visualização da programação visual ou textual que o
compõe (DYNAMO, 2018c). O objetivo da criação dos Custom Nodes é possibilitar, de
forma organizada, o uso de funções extensas que utilizem muitos nodes ou que
necessitem ser repetidas por diversas vezes em uma rotina. Além disso, a criação de
um Custom Node serve como uma maneira de criar funções inovadoras, e
compartilhar conteúdo com a comunidade de usuários: conforme são programados
nodes que ampliam o potencial de programação do Dynamo, estes podem ser
publicados na forma de pacotes que podem ser baixados – caracterizando os Custom
Packages ou simplesmente pacotes – conjuntos organizados de Custom Nodes
desenvolvidos sob um tema ou funções determinadas.
Para exemplificar isto, na Figura 24 é apresentado o Custom Node “Room Element
Collector”, do pacote Lunchbox. A funcionalidade deste node em específico é ampliar
as opções de seleção de ambientes no Revit, fornecendo uma série de possíveis
outputs que dificilmente são programados e organizados utilizando apenas funções
básicas do Dynamo. Ao abrir o Custom Node pelo Dynamo, é possível verificar sua
programação interna, composta por um node de Python Script e diversos nodes de
organização de listas.
59
Figura 24 - Estruturação interna de um node customizado do pacote Lunchbox
Fonte: Autor (2018).
O uso do node Python Script se caracteriza em mais uma maneira de inserir
programação textual no Dynamo e, portanto, é mais um componente híbrido na
extensão. Python é uma linguagem textual orientada a objetos, de código aberto,
suportada por muitas extensões e plug-ins que operam com VPL, servindo como
uma opção para usuários mais avançados, permitindo ultrapassar muitas das
limitações inerentes de ferramentas como o Dynamo e Grasshopper (MACKEY;
ROUDSARI, 2018). Outra possibilidade é a de trazer funções de bibliotecas de outros
softwares como o Navisworks para dentro do ambiente de programação,
possibilitando uma maior interoperabilidade com estes (AUTODESK, 2017a;
DYNAMO, 2018c; DYNAMONODES, 2018). Assim como o DesignScript, também
possibilita tornar o código da rotina mais conciso, organizado e compacto.
Na Figura 25, o node de Python Script utilizado no Room Element Collector é aberto, o
que possibilita verificar o código utilizado para realizar parte das funções, por meio
da linguagem Python.
60
Figura 25 - Estruturação interna de um node Python Script
Fonte: Autor (2018).
Com todas estas possibilidades de captura de informações, manipulação de listas,
criação de regras, customização e importação de componentes criados pelas
comunidades, bem como as múltiplas maneiras de programar, é possível criar uma
grande diversidade de ferramentas, permitindo que usuários com diferentes graus de
conhecimento acerca de VPL e TPL definam rotinas para atingir seus objetivos de
automatização de projeto. Na Figura 26, é apresentada uma composição de um
usuário da comunidade do Dynamo, um workflow de que permite notar algumas das
potencialidades elencadas. Foram vinculados elementos BIM de famílias adaptivas –
condicionadas a parâmetros externos como, por exemplo, abertura ou inclinação das
peças vinculadas ao posicionamento solar, para desenvolver a geometria da fachada.
61
Figura 26 - Rotina para composição de estrutura utilizando componentes adaptivos
Fonte: Dynamo Gallery (DYNAMO, 2018a).
Após a apresentação destes conceitos acerca do Dynamo, se faz necessário detalhar
alguns dos aplicativos e principais pacotes da comunidade empregados na pesquisa.
As seções seguintes são dedicadas à apresentação do organizador de rotinas Dyno
Browser, utilizado para viabilizar o acesso aos plug-ins; e os Custom Packages de
destaque: Data-Shapes (DATA-SHAPES, 2017) e Ladybug (LADYBUG, 2018), que
possibilitaram ampliar o potencial da programação desenvolvida.
3.1.1 Dyno Browser
Em um esforço para possibilitar a difusão de rotinas do Dynamo para profissionais
com poucos conhecimentos de programação, Alexey Lobanov desenvolveu o Dyno
Browser, um plug-in para Revit que busca organizar, gerenciar e rodar rotinas do
Dynamo sem que este precise ser aberto no Revit (PRORUBIM, 2017). Dyno Browser
está vinculado à interface da plataforma Revit e permite, dentre outras funções, a
criação de botões em abas customizadas (Figura 27), o controle da execução de
múltiplas rotinas e a consolidação de suítes de ferramentas programadas no
Dynamo.
Figura 27 - Botões de interface no Revit criados a partir da programação do Dyno Browser
Fonte: Manual de uso do Dyno Browser (PRORUBIM, 2017).
62
As rotinas do Dynamo podem ser organizadas em pastas e pré-configuradas com
alguns valores, chamados de presets – opções que permitem a mudança de inputs
como valores, palavras, operações booleanas e algumas outras opções sem abrir o
Dynamo (PRORUBIM, 2017). Assim, conforme um botão é clicado em uma das abas
das rotinas configuradas, as funcionalidades programadas da mesma são executadas,
e se algum preset for configurado, sua informação será inserida antes da execução.
Isto permite agilizar os fluxos de trabalho por meio de um acesso rápido e de fácil
uso, pois rotinas prontas e de funcionamento estável podem ser utilizadas repetida e
interativamente, facilitando tarefas braçais e que consomem tempo, e automatizando
fluxos de informação para potencializar o gerenciamento de dados.
O monitoramento das rotinas executadas é possível devido a uma janela dedicada
para a interface do Dyno Browser no Revit (Figura 28), o que permite a visualização
de relatórios de tempo de execução, avisos e erros encontrados – possibilitando atuar
também na otimização do processamento e correção de erros da programação
desenvolvida. Além disso, é possível editar os valores dos parâmetros presets da
rotina, agilizando parcialmente a modificação de inputs.
Figura 28 - Edição de parâmetros preset e resultados da execução de uma rotina pelo Revit
Fonte: Manual de uso do Dyno Browser (PRORUBIM, 2017).
63
A Autodesk desenvolveu ferramenta semelhante – o Dynamo Player, incluído no
Revit 2018, cujas funções principais também estão relacionadas à organização e
execução de rotinas do Dynamo diretamente pelo Revit (AUTODESK, 2017b).
Contudo, seu desenvolvimento ainda está em andamento e, até a data deste trabalho,
não permite, por exemplo, a construção de uma aba de ferramentas própria
efetivamente integrada à plataforma.
A importância do Dyno Browser para a presente pesquisa é sua capacidade de tornar
a interface amigável, automatizada e conectada ao Revit, permitindo que as rotinas
de programação desenvolvidas no Dynamo possam se constituir em plug-ins
intuitivos e que possibilitem articular e atingir os objetivos propostos.
3.1.2 Data-shapes
Um dos problemas da manipulação de dados através do Dynamo é a falta de uma
interface estruturada para inputs do usuário. As informações dadas na programação
interna de rotinas feitas apenas com os nodes básicos oferecem pouca customização
em relação às janelas pop-up, o que complica a criação de soluções de programação
direcionadas a um usuário final que não possui entendimento das funcionalidades
do Dynamo.
Pensando nestes entraves, o membro Mostafa El Ayoubi, da comunidade de usuários
do Dynamo, desenvolveu através de extensos códigos com linguagem Python, o
pacote Data-Shapes (DATA-SHAPES, 2017), um conjunto de nodes voltados para
criação de janelas e flexibilização de inputs do projetista, de modo a aumentar a
facilidade de uso de plug-ins criados no Dynamo.
O funcionamento dos nodes Data-Shapes permite a criação de caixas de texto,
checkboxes, menus dropdown, botões de busca por arquivos e pastas, e outras
funções, conforme exemplificado na Figura 29. Isto é feito por meio de janelas pop-up,
que podem ser apresentadas ao usuário antes que as funções de rotinas do Dynamo
sejam executadas (DATA-SHAPES, 2017).
64
Figura 29 - Exemplos de interfaces configuráveis no Data-Shapes
Fonte: adaptado de Data-Shapes (2017).
Assim, é possível delegar ao usuário o papel de informar algum parâmetro, definir
os limites de regras, escolher a maneira como o programa irá realizar algum cálculo
ou verificação – por meio de condicionantes, entre muitas outras aplicações. Nesta
situação, o input ficará vinculado à decisão do usuário no momento de execução da
rotina, e não mais na manipulação de valores, palavras e operações booleanas dentro
do ambiente de programação do Dynamo, o que reforça a facilidade no uso.
O principal potencial deste pacote na presente pesquisa está em direcionar o
processamento de rotinas conforme a tomada de decisão do usuário a partir da
flexibilização dos inputs por meio de janelas de interface. Isto possibilita ampliar a
importação de informações externas, seguir fluxogramas de múltiplos caminhos, e
levar em conta preferências e limitantes declarados pelo usuário. Estes aspectos serão
abordados mais adiante neste trabalho.
Quando utilizado juntamente ao Dyno Browser, é possível construir uma série de
ferramentas que, além de integradas à interface do Revit sem necessitar abrir o
Dynamo, permitem ao usuário informar alguns parâmetros, importar arquivos, e
estabelecer o comportamento desejado na rotina – de forma semelhante aos presets
descritos no item 3.1.1, porém, com a adição de janelas pop-up e maior possibilidade
de captura de parâmetros.
65
3.1.3 Ladybug e Honeybee
Ladybug Tools é um conjunto de ferramentas desenvolvido originalmente por
Mostapha Sadeghipour Roudsari, inicialmente para o plug-in Grasshopper para
Rhinoceros3D (GRASSHOPPER, 2018). É de formato aberto, utiliza a linguagem
Python de programação e suas funcionalidades recentemente vêm sendo adaptadas e
transportadas para o Dynamo pela equipe de desenvolvedores.
Consiste em funções voltadas para o projeto de edificações sustentáveis ou
ambientalmente conscientes por meio da simulação e verificação da performance de
ambientes. O Ladybug Tools funciona em conjunto com softwares de referência na
área de desempenho, como o EnergyPlus (ENERGYPLUS, 2017) e Radiance
(RADIANCE, 2017), funcionando no intercâmbio de informações e na
operacionalização de funções destes softwares no ambiente de modelagem 3D ou
BIM (LADYBUG, 2018).
Atualmente, o Ladybug Tools conta com 4 principais ferramentas (Figura 30):
Ladybug – a ferramenta que dá nome ao grupo, para análises de dados climáticos e
produção de visualizações interativas; Honeybee – para criação, execução, e
visualização de simulações de luz natural, também possuindo opções envolvendo
modelos energéticos e para conforto térmico; Butterfly – ferramenta de simulações de
CFD (Computational Fluid Dynamics), envolvendo análises de ventilação; e Dragonfly
– utilizado na escala do urbano, para análise de fenômenos climáticos como ilhas de
calor, precipitação, entre outras. Outra ferramenta em desenvolvimento, atualmente
no estágio alpha, é o Dynosaur, exclusivo para Dynamo, voltado para a extração de
parâmetros geométricos e não geométricos no interior de ambientes do Revit – algo
que ainda é feito com as funções básicas do Dynamo, de forma não otimizada
(GITHUB, 2018b).
Figura 30 - Componentes do Ladybug Tools
Fonte: Ladybug (2018).
No presente trabalho, as ferramentas mais utilizadas são o próprio Ladybug e o
Honeybee. Embora seu uso será detalhado mais adiante neste trabalho, é importante
ressaltar suas principais funções. Ladybug manipula arquivos de informações
climáticas no formato .EPW (Energy Plus Weather), e possibilita uma variedade de
66
outputs gráficos por meio de estudos solares, ray-tracing, análises horárias e muitas
outras (Figura 31), para dar suporte aos processos de projeto. O Honeybee é utilizado
para interpretar as informações climáticas e, por meio de análises de iluminação
natural, providenciar relatórios preenchidos com cores vinculadas aos resultados das
simulações, entre outras funções (Figura 32). Conforme Roudsari et al. (2013), Viola e
Roudsari (2013), o potencial em utilizar Ladybug e Honeybee em ferramentas de VPL
está tanto no feedback instantâneo conforme as alterações do usuário, como no alto
grau de customização de ferramentas próprias, o que permite direcionar a
programação para atingir os objetivos mais específicos do projetista – no caso deste
trabalho, o atendimento de alguns requisitos da Norma de Desempenho.
Figura 31 - Coleção de funcionalidades do pacote Ladybug
Fonte: Ladybug (2018).
Figura 32 - Coleção de funcionalidades do pacote Honeybee
Fonte: Ladybug (2018).
67
No Dynamo, Ladybug e Honeybee estão disponíveis como Custom Packages,
utilizando nodes de importação de arquivos, traçado da trajetória solar conforme
informações climáticas (.epw), criação de grids de análise em ambientes (Rooms) do
Revit, análise de iluminância por meio de Ray-tracing, entre muitos outros. Embora
muitas de suas funcionalidades ainda são limitadas e estão sendo adaptadas da
versão do Grasshopper, seu potencial pode ser aumentado na medida em que os
nodes possibilitem capturar e manipular informações presentes apenas nos softwares
BIM e não apenas na modelagem tridimensional (GRAPHISOFT, 2017; LADYBUG,
2018).
Em relação à comunidade de usuários, destaca-se o Hydrashare, repositório online
de rotinas de programação que exemplificam alguns usos do Ladybug Tools, tanto
para Grasshopper, como para Dynamo, disponibilizando as rotinas e pacotes
necessários para execução de diversas operações (HYDRA, 2018). Na Figura 33, um
exemplo de análise horária de luz solar foi publicado e sua rotina é disponibilizada,
juntamente com vídeos demonstrativos, destacando o uso de Ladybug Tools em
painéis solares no Dynamo.
Figura 33 - Aplicação de Ladybug Tools no Dynamo para estudos de painéis solares
Fonte: Hydra (2018).
68
4. PERFORMANCE DAS EDIFICAÇÕES
Visando apresentar contextualização acerca do tema específico para o
desenvolvimento dos artefatos do presente trabalho, este capítulo apresenta revisão
bibliográfica acerca de alguns dos principais conceitos a serem discutidos, com
trabalhos acadêmicos onde foram pesquisadas possíveis interações e sinergias entre
conceitos de performance e desempenho das edificações em relação às ferramentas
BIM, considerando também as mudanças nos processos de projeto e os avanços
tecnológicos.
4.1 BIM aplicado à performance
No processo de projeto, melhorias relacionadas à performance podem ser percebidas,
dentre outras maneiras, através de padronização de processos, como atendimento
aos padrões de desempenho e pela verificação, simulação e processamento
matemático de informações relativas ao comportamento dinâmico da edificação. Em
relação à bibliografia que contempla tanto a performance das edificações, como o
contexto de programação no qual esta pesquisa se concentra, destacam-se os
trabalhos a seguir.
Conforme Hensen e Lamberts (2011), performance pode ser definida como um
conjunto de aspectos relacionados ao conforto, desempenho e análise de sistemas
construtivos por óticas da temperatura, acústica, iluminação, impacto ambiental,
durabilidade, consumo de energia, construtibilidade, manutenção, entre outras.
Segundo os autores, o potencial da interpretação destes aspectos está em sua
simulação e manipulação, de modo que o projeto possa ser adequado conforme
resultados de predições em diferentes cenários. Tais abordagens servem como um
background em potencial para o BIM e suas perspectivas multidimensionais – onde
novas camadas de complexidade de análise podem caracterizar novos processos ao
longo do ciclo de vida da edificação (BIM 6D, 7D e assim por diante) (SANHUDO,
2016).
Tal perspectiva do processo de projeto exige que informações relativas ao
comportamento da edificação sejam acionáveis logo nas etapas iniciais. Por vezes, a
simulação de tal comportamento só é realizada após a conclusão de etapas de escolha
de forma, materiais e soluções técnicas, não sendo de fato integrada no processo de
projeto – uma situação que, nos processos tradicionais, pode resultar em
modificações próximas à execução dos empreendimentos, onde o custo para definir
soluções e atender a performance desejada é muito superior (SCHLUETER;
THESSELING, 2009).
69
Este conjunto de decisões tecnológicas a serem tomadas nos projetos de arquitetura,
priorizando a performance de seus sistemas é abordado por Negendahl (2015), Shi e
Yang (2013) como performance-driven architecture, cuja ênfase de projeto se dá por
meio da otimização abrangente e integrada de diversos indicadores de desempenho
das edificações. Tal conceito toma uma visão holística acerca da performance
ecológica e ambiental dos empreendimentos, visando compreender o
comportamento dos sistemas para realizar decisões conscientes, mas não
abandonando a forma, estética e função das edificações.
Em um esforço para facilitar decisões informadas desde as fases iniciais do projeto de
edificações, até as etapas de detalhamento e especificação de sistemas, Papamichael
(1998) propôs o BDA – Building Design Avisor, um software de uso concorrente de
múltiplas ferramentas de simulação e seus respectivos bancos de dados, para tornar
os resultados quantitativos de tais simulações acionáveis durante as etapas de projeto
por meio de julgamento multi-critérios – conforto, custo, estética, impacto ambiental,
entre outros (PAPAMICHAEL, 1998). O BDA foi descontinuado alguns anos depois,
devido às limitações relacionadas ao seu ambiente de modelagem e restrições de
processamento dos computadores da época.
Em outro estudo, Papamichael et al. (1996) relatam que, para possibilitar a tomada de
decisões que contemplem a complexa gama de variáveis apresentada no
comportamento de uma edificação, se faz necessário inserir a computação no design,
para dar suporte às decisões, considerando estratégias energeticamente eficientes ao
longo do processo de projeto, onde os projetistas podem avaliar diferentes contextos
e simular diferentes soluções para seus problemas.
Para os autores (PAPAMICHAEL et al., 1996), o uso de softwares de simulação
possibilita contribuir para o processo de projeto por meio de decisões mais
informadas acerca do que está sendo implementado na edificação em termos de
materiais e sistemas, o que pode ser traduzido em projetos com maior nível de
qualidade das construções.
Contudo, um dos principais problemas levantados pelos autores em relação às
ferramentas de simulações é que muitas delas foram feitas direcionadas para uso
acadêmico em detrimento da aplicação em cenários profissionais. Muitos dos
softwares de análise e simulação de critérios de edificações foram originalmente
desenvolvidos por pesquisadores, com ampla experiência na área, o que infelizmente
faz com que as ferramentas exijam alto nível de abstração e conhecimento para
interpretação de seus resultados (PAPAMICHAEL, 1998). Enquanto que os inputs
requerem uma preparação de arquivos que exige muito tempo do projetista, os
outputs são por vezes apresentados em tabelas com informações de difícil
70
interpretação, revisão e implementação em projetos reais. Tais problemas são
apontados como um dos motivos pelos quais tais ferramentas eram – e em alguns
casos, ainda são – pouco utilizadas pela comunidade de projetistas (PAPAMICHAEL
et al., 1996).
A introdução das plataformas paramétricas modificou o design voltado para a
performance de maneira disruptiva. Com os avanços da modelagem computacional,
design generativo, adaptativo, e otimização multi-critérios substituindo os modelos
físicos simplificados, é possível executar estes processos de maneira mais próxima às
etapas de concepção da edificação, agregando melhorias que podem ser verificadas
com grande precisão ao longo do ciclos de vida (VIOLA; ROUDSARI, 2013).
Ainda que a importância do projeto voltado para eficiência e sustentabilidade tenha
crescido na indústria da construção, análises de energia e desempenho não estão
totalmente integradas aos processos de projeto BIM, com tais etapas usualmente
sendo feitas apenas depois que o projeto arquitetônico foi completado (SCHLUETER;
THESSELING, 2009).
Como uma alternativa para direcionar as informações de performance para um
ambiente onde estas sejam efetivamente utilizadas ou verificadas em simulações,
alguns autores desenvolveram extensões, plug-ins ou programas complementares às
plataformas, de modo a possibilitar uma maior integração da etapa de tomada de
decisão nos processos. Em tal cenário, plug-ins podem aumentar a viabilidade de
realizar avaliações de diferentes soluções tecnológicas nas fases iniciais do projeto,
possibilitando que projetistas foquem em atingir menores impactos ao longo do ciclo
de vida das edificações através de maior atenção ao desempenho e eficiência
energética em seus projetos (JALAEI; JRADE, 2014).
Embora a customização de software seja uma prática comum em áreas como
engenharia mecânica e design, é algo que ainda está em desenvolvimento na
arquitetura, considerando as crescentes necessidades de otimização dos processos de
projeto e melhorias na avaliação da performance (MATCHA; QUASTEN, 2009).
Por outra perspectiva, o crescente interesse em projetos sustentáveis, amplificado por
certificações ambientais como LEED (Leadership in Energy and Environmental Design) e
BREEAM (Building Research Establishment Environmental Assessment Method), têm se
tornado uma maneira de manifestar a eficiência dos sistemas construtivos e de
planejar processos e tomada de decisões tecnológicas, alterando processos de projeto
na medida em que levam em consideração impactos ambientais e influências das
escolhas de sistema construtivo ao longo do ciclo de vida (JALAEI; JRADE, 2014).
71
Neste sentido, Wu (2010) propôs, através de plug-ins desenvolvidos pelo Revit API,
uma estruturação de bancos de dados capazes de avaliar requerimentos para a
certificação ambiental LEED. No trabalho, o pesquisador utilizou um sistema de
detecção de sintaxe e contexto para avaliar como cada aspecto da certificação poderia
ser integrado no ambiente BIM, de modo a facilitar e automatizar processo de
submissão e obtenção de créditos dos requisitos, possibilitando às partes envolvidas
tomar um posicionamento estratégico gerencial conforme suas metas de certificação.
Plug-ins também podem ser utilizados para facilitar análises de sustentabilidade
aliadas ao manejo de custos e prazos para projetos de construção. Enquanto tais
tarefas por vezes são complicadas pela grande quantidade de alternativas de
sistemas construtivos, aliado ao cenário mutável dos processos de projeto e tomada
de decisão, uma ferramenta externa pode, por exemplo, auxiliar na sincronização de
bancos de dados e automatização de processos. Por meio da relação entre
características conhecidas do modelo com outros softwares ou servidores que
contenham informações referenciais para a tarefa a ser realizada, é possível agilizar
tomadas de decisão e obter um maior leque de soluções alternativas para problemas
específicos (LI, 2016).
Focar em áreas específicas de certificação tem sido uma maneira para guiar o
desenvolvimento de plug-ins na bibliografia recente, com aplicações voltadas para
áreas como manejo de águas de chuva (SANHUDO, 2016), uso operacional de
energia, emissões de carbono (STADEL et al., 2011) e materiais sustentáveis
(ZHANG; CHEN; KANG, 2015), possibilitando decisões estratégicas e informadas
nos processos de certificação.
Sanhudo (2016) utilizou rotinas da extensão do Revit, Dynamo, para desenvolver um
plug-in voltado para o manejo de águas de chuva, visando atender segmentos
específicos da certificação LEED. O autor demonstra as potencialidades atingidas por
meio da programação para atingir novos patamares de automatização e melhoria nos
processos de escolha em edificações sustentáveis, por meio do cálculo e verificação
de requisitos em situações dificilmente verificáveis apenas com os recursos básicos
de plataformas BIM.
Zhang, Chen e Kang (2015) desenvolveram plug-ins para monitorar aspectos de
performance de edificações, também tomando como base os requisitos da certificação
LEED, porém, com foco nas etapas de execução. Os autores utilizaram uma interface
onde parâmetros compartilhados de materiais sustentáveis são inseridos no ambiente
de projeto, auxiliando na tomada de decisão para atingir requisitos da certificação
enquanto o projeto está nas etapas iniciais.
72
Similarmente, Stadel et al. (2011) avaliaram as potencialidades da programação
voltada para sustentabilidade na plataforma Revit, com ênfase na integração de
dados de emissão de carbono pelas soluções adotadas em projeto. O estudo mostrou
que plug-ins e extensões relacionados à eficiência energética também podem dar
enfoque ao estudo de análises de impacto ambiental já nas etapas iniciais de projeto.
Tal situação é também estudada por Jalaei e Jrade (2014), que destacam que plug-ins
podem aumentar a viabilidade de comparação de diferentes soluções de projeto
sustentável em momentos precoces. Isto possibilita a arquitetos uma maior
amplitude de visão e consciência sobre escolhas tecnológicas e consequentemente um
projeto com menores impactos e sistemas mais eficientes.
Por uma ótica de requisitos de desempenho em relação à segurança da edificação,
Zhang et al. (2013) apresentaram algoritmos para verificar, de forma automatizada,
riscos de queda de altura durante a execução de obras, por meio de informações
geométricas e semânticas nos modelos BIM. Uma plataforma de análise foi
programada para percorrer modelos e checar no cronograma de atividades
vinculado se haveria ocorrência de tarefas sem a conclusão de instalações de
segurança ou vedações. Tal abordagem também permitiu antecipar que tipos de
ações corretivas deveriam ser empregadas em cada caso.
No Brasil, Brigitte e Ruschel (2016) recentemente realizaram um trabalho
investigativo acerca das ferramentas computacionais direcionadas à análise de
desempenho das edificações nas etapas iniciais de projeto. Por meio da identificação
de parâmetros necessários para simulações de desempenho térmico, acústico e
lumínico, consumo de água, materiais e acessibilidade, as autoras propõem diretrizes
para o processo de projeto, propondo uma sequência de execução das análises e
simulações em modelagens BIM, considerando as diferentes ferramentas disponíveis.
Consoante a estas inovações, os processos BIM vêm se adequando muito bem aos
novos desafios da sustentabilidade e da eficiência energética nas edificações.
Modelos inteligentes ricos em informação, processos mais flexíveis e atentos ao
contexto de performance possibilitam incluir estratégias no ambiente de projeto,
identificando oportunidades de melhoria da qualidade das edificações através da
modelagem. Contudo, é notável a necessidade de customização e adaptação de
plataformas já existentes para que a inclusão destas novas estratégias seja efetiva.
No sentido de avaliar a possibilidade de integração entre plataformas BIM e alguns
softwares comerciais de simulação de desempenho, Kirkegaard e Kamari (2017)
publicaram um relatório que agrupa estudos sobre o tema, com foco no interior de
edificações. O relatório contempla aspectos de conforto acústico, térmico e luminoso,
bem como umidade, ventilação e consumo de energia, buscando investigar se
73
algumas ferramentas de simulação do mercado podem ser integradas ao software
BIM de arquitetura Revit.
Conforme resultados do estudo, muitos dos softwares de simulação analisados não
possuem sólida interoperabilidade com modelos BIM, por vezes transportando
apenas geometria, por vezes com trânsito da informação limitado a máscaras de
desenho 2D, e não informações de parâmetros como materiais, o que impossibilita a
completa implementação no processo BIM.
Um dos grandes problemas foi a necessidade de reinserir parâmetros não-
geométricos, o que acaba por eliminar o potencial da plataforma BIM para as
simulações – utilizando apenas a casca geométrica das dimensões da edificação, visto
que há considerável retrabalho e perda de informações. Outro ponto é que a grande
quantidade de informações a serem inseridas para a simulação desencoraja a
realização das análises em etapas iniciais do projeto, o que é contraprodutivo do
ponto de vista processual com a abordagem BIM (KIRKEGAARD; KAMARI, 2017).
Conforme os autores (KIRKEGAARRD; KAMARI, 2017), dentre alguns dos softwares
ou extensões levantadas no estudo que oferecem um grau maior de integração com
as plataformas BIM, destacam-se: Green Building Studio – ferramenta que pode ser
utilizada para efetuar simulações paralelamente ao desenvolvimento do modelo
BIM, continuamente dando suporte às decisões durante o projeto; e o Insight 360 –
um plug-in para Revit que possibilita simular aspectos de eficiência energética como
aquecimento e resfriamento, bem como iluminação diretamente no modelo
(AUTODESK, 2018).
Os autores concluem o estudo ressaltando que, para as ferramentas de análise de
performance serem úteis e sobreviver às constantes melhorias de softwares BIM,
precisam desenvolver interoperabilidade com estes (KIRKEGAARD; KAMARI,
2017). Outro grande desafio é a capacidade de vincular as simulações diretamente no
modelo BIM, onde o impacto das mudanças pode ser observado através de seu
robusto corpo de informações e possibilitar a exploração do design (AISH, 2013a)
durante o desenvolvimento dos projetos.
Embora existam diversas ferramentas de simulação disponíveis no mercado, a
possibilidade de vincular informações além da geometria da edificação ainda é um
desafio. Contudo, este desafio pode ser amenizado conforme usuários de
ferramentas de programação desenvolvem pontes de interoperabilidade por meio de
soluções customizadas, ou ainda, criam suas próprias aplicações com base em
softwares referenciais ou certificados (MACKEY; ROUDSARI, 2018).
74
4.2 Norma de Desempenho Brasileira
No Brasil, a Norma de Desempenho NBR 15.575/2013 (ABNT, 2013a), em vigor desde
julho de 2013, recentemente tranformou o setor de Arquitetura, Engenharia e
Construção, fazendo com que fornecedores e projetistas necessitem se adaptar a
novos processos de produção. Arquitetos e engenheiros revisitam seus projetos para
atender especificações relacionadas a sistemas construtivos, levando em consideração
aspectos como conforto, segurança e durabilidade, para garantir a satisfação do
usuário durante o uso da edificação.
Tais requisitos de qualidade demandam um maior detalhamento das informações
associadas à edificação e melhorias nos processos de tomada de decisão – uma série
de mudanças que altera os processos de projeto já estabelecidos na medida em que
insere prerrogativas a serem atendidas e aumenta a complexidade das análises.
Em relação a sua estrutura, a Norma de Desempenho é organizada conforme
modelos internacionais de normalização de desempenho (CBIC, 2013). É um
documento dividido em seis partes, sendo a primeira relativa a Requisitos Gerais e as
outras cinco por meio da separação de sistemas construtivos da edificação:
• NBR 15575-1: Requisitos gerais
• NBR 15575-2: Requisitos para os sistemas estruturais
• NBR 15575-3: Requisitos para os sistemas de pisos
• NBR 15575-4: Requisitos para os sistemas de vedações verticais internas e externas
• NBR 15575-5: Requisitos para sistemas de coberturas
• NBR 15575-6: Requisitos para os sistemas hidrossanitários
O foco geral da Norma de Desempenho está em atender as exigências de usuários,
classificadas nas categorias de Segurança, Habitabilidade e Sustentabilidade (Figura
34), por meio da qualidade dos sistemas construtivos e seu comportamento durante a
operação da edificação. Isto é feito por meio de requisitos (qualitativos), critérios
(quantitativos e premissas) e métodos de avaliação, inputados aos sistemas para
atendimento aos níveis de desempenho Mínimo, Intermediário ou Superior.
75
Figura 34 - Quadro de exigências de desempenho
Segurança Habitabilidade Sustentabilidade
Segurança
estrutural; Contra
fogo; no Uso e
Operação.
Estanqueidade; Desempenho térmico; acústico;
lumínico; Saúde, higiene e qualidade do ar;
Funcionalidade e Acessibilidade; Conforto
Tátil e Antropodinâmico.
Durabilidade;
Manutenibilidade;
Impacto Ambiental
Fonte: adaptado de NBR 15575-1 (ABNT,2013a).
Contudo, o objetivo da Norma de Desempenho é estabelecer estes requisitos,
critérios e métodos voltados ao desempenho independentemente dos materiais,
métodos construtivos empregados e formas de dimensionamento nas soluções
projetuais. Isto incentiva o desenvolvimento tecnológico do setor, ao passo em que
permite a inserção de novas tecnologias na construção, e direciona a melhoria dos
sistemas construtivos já consagrados (SOUZA; KERN; TUTIKIAN, 2018).
Enquanto que outras normas técnicas são voltadas para a prescrição de
características como dimensões e propriedades de produtos, a Norma de
Desempenho apenas estabelece o comportamento necessário no uso. Desta forma, a
Norma de Desempenho possibilita a criação de um ambiente de inovação
tecnológica, pois direciona fornecedores a atenderem seus critérios específicos e,
conscientiza projetistas acerca do impacto de suas escolhas no uso.
Este cenário, aliado ao amadurecimento da indústria da construção, juntamente com
a chegada de novos processos como o BIM, possibilita que o setor evolua como um
todo, partindo da premissa de que haverá o refinamento tecnológico necessário tanto
nos processos de produção como nos processos de projeto.
Em relação a sua aplicabilidade, embora normas técnicas não possuam força de lei,
seu atendimento é obrigatório, principalmente devido ao Código de Defesa do
Consumidor (Lei nº 8078/1990) – que proíbe a fornecedores colocar no mercado
produtos em desacordo com as normas; e à Lei das Licitações (Lei nº 8666/1993) – que
obriga o atendimento às normas em contratações com órgãos públicos.
Quanto a seu histórico e origens, por meio de um projeto de um método de avaliação
de sistemas construtivos inovadores, financiado pela Caixa Econômica Federal, em
2010 foi publicada a NBR 15575/2010 – Edifícios habitacionais de até cinco
pavimentos – Desempenho. Este documento foi reavaliado e após passar por
diversas discussões e revisões junto à indústria de construção, devido a seus
impactos em toda a cadeia produtiva, tornou-se a atual norma em vigor NBR
15575/2013 – Edificações habitacionais – Desempenho.
Há uma tendência mundial para desenvolvimento e adaptação de normativas de
desempenho, com muitos avanços em países estrangeiros que visam tanto a melhoria
76
dos sistemas construtivos tradicionais como a inovação tecnológica (SOUZA; KERN;
TUTIKIAN, 2018). Segundo os autores, os primeiros esforços para implementação de
normativas voltadas para o desempenho na construção começaram nos Estados
Unidos, em 1925, com relatórios intitulados “Práticas recomendadas para arranjo de
códigos de construção”.
Ao longo da história destacam-se outros implementos, como a comissão CIB W60 –
The performance concept in building, de 1967; as normas ISO 6240/1980 – Performance
standards in buildings: contentes and presentation; ISO 6241/1984 – Performance standards
in buildings: principles for their preparation and factors to be considered; e ISO 7162/1992 –
Performance standards in buildings: contents and format of standards for evaluation of
performance considered; o eurocode EN 1990/2002 – Basis of structural design. Também
destaca-se nos Estados Unidos, o ICC Performance code for buildings and facilities, desde
1994; no Canadá, o Objective-based building code, desde 2005; e na Espanha, o Código
Técnico de la Edificación (CTE), criado em 2006, entre muitos outros (SOUZA; KERN;
TUTIKIAN, 2018).
Em relação às novas competências e responsabilidades imputadas aos agentes
envolvidos, Souza, Kern e Tutikian (2018) relatam que, devido ao fato de que o
desempenho dos sistemas construtivos depende de diversos fatores como materiais
empregados e suas ligações; técnicas construtivas utilizadas; e capacitação da mão de
obra executiva, o processo de atendimento à Norma de Desempenho é algo que
necessita de forte colaboração entre os envolvidos na cadeia produtiva de projeto e
execução da edificação.
CBIC (2013) lançou o Guia Orientativo para Atendimento à Norma em um esforço
para disseminação de critérios normativos, contendo exemplos de disposições
construtivas e informações de referência para projetistas. Tal esforço busca
apresentar a norma às partes interessadas, como uma maneira de compreender a
qualidade das edificações habitacionais por meio do conhecimento de suas
incumbências e responsabilidades, visando o amadurecimento e melhoria da relação
de consumo no mercado da construção como um todo.
Em relação às responsabilidades imputadas a cada agente, enquanto que
fornecedores devem caracterizar o desempenho e comprovar seu atendimento à
normativa em seus produtos; os projetistas devem estabelecer a VUP (Vida Útil de
Produto) de suas soluções, e especificar os tipos de materiais, produtos e processos
envolvidos nas decisões tecnológicas; os construtores devem identificar riscos,
providenciar estudos técnicos, comprovar o atendimento de seus sistemas e exigir
dos fornecedores o atendimento dos materiais (ABNT, 2013a). Estas novas
responsabilidades implicam em mudanças tanto no processo de projeto, como na
77
produção, na cadeia de fornecedores e na fiscalização (SOUZA; KERN; TUTIKIAN,
2018).
Além das responsabilidades dos atores da cadeia de projeto e produção, o próprio
usuário possui uma responsabilidade relacionada ao uso da edificação: deve seguir
as recomendações de operação e manutenção dispostas no documento Manual do
Proprietário (documento que deve ser disponibilizado pelo construtor), onde são
especificadas as manutenções corretivas e preventivas dos sistemas empregados, de
modo que estes possam manter seu desempenho ao longo da vida útil projetada
(ABNT, 2013a).
Em relação aos principais desafios na adaptação de processos de projeto e construção
devido à NBR 15.575/2013, Souza, Kern e Tutikian (2018) levantaram em um estudo
recente alguns dos principais impactos encontrados no atendimento ao desempenho
em um empreendimento habitacional. Destacam-se: a necessidade da presença de
um laboratório ou ITA (Instituição Técnica Avaliadora) acompanhando os processos
de ensaio e execução; a necessidade de adotar novas composições de sistemas
construtivos (como blocos cerâmicos estruturais, por vezes com camadas de areia
entre paredes) e com estes, novos procedimentos de trabalho relacionados; maior
detalhamento e especificações nos projetos; investimento de materiais e insumos para
ensaios em laboratório e em obra; e a intensificação de simulações computacionais
durante o processo de projeto.
Além disso, os autores (SOUZA; KERN; TUTIKIAN, 2018) relatam que foi necessário
consultar normas internacionais quando parâmetros como Vida Útil de Projeto não
possuíam registros nacionais.
Alguns desafios voltados para o processo de projeto e atendimento aos requisitos são
levantados por Cotta e Andery (2018): a falta de conhecimento técnico em
construtoras e escritórios de projeto; ausência de informações e especificações de
desempenho em materiais de fabricantes; e a falta de integração entre as interfaces
técnicas (arquitetura e engenharia) e o setor imobiliário e incorporação.
Para os autores (COTTA; ANDERY, 2018), para que as empresas do setor de projeto e
execução de edificações encarem estes desafios, se faz necessária uma mudança
cultural profunda nas empresas, instrumentalizar o processo de projeto por meio de
ferramentas que cubram os aspectos tecnológicos e requisitos da Norma de
Desempenho, desde planilhas, documentos, checklists e fluxogramas processuais.
Além disso, o atendimento efetivo da Norma de Desempenho requer mecanismos de
gestão de qualidade e o rigor na escolha de materiais (SILVA JÚNIOR; MITIDIERI
FILHO, 2015).
78
4.3 BIM e a Norma de Desempenho
Devido ao fato de que a Norma de Desempenho trouxe uma série de novas
informações e condicionantes a serem interpretadas no ambiente de projeto, alguns
autores (COSTA; ILHA, 2017; NARDELLI; OLIVEIRA, 2013; SILVA; ARANTES,
2016; SILVA JÚNIOR; MITIDIERI FILHO, 2015) realizaram pesquisas que apontam
para um potencial de integração e sinergia existente entre a NBR 15.575/2013 e os
processos e ferramentas BIM.
Silva e Arantes (2016) realizaram um estudo buscando identificar possibilidades de
automatização do atendimento a requisitos da Norma de Desempenho por meio da
inserção de regras no software BIM Solibri Model Checker – um programa que
percorre a geometria e informação de modelos BIM, analisando e identificando
possíveis irregularidades ou violações, conforme condicionantes determinadas pelo
usuário (EASTMAN et al., 2008), tais condicionantes podem ser, por exemplo:
valores de parâmetros de famílias, dimensões mínimas ou relações obrigatórias entre
elementos.
Para os autores (SILVA; ARANTES, 2018), o Solibri Model Checker possui algumas
limitações, visto que suas regras não podem ser profundamente customizadas pelo
usuário, necessitando-se o uso de templates. Além disso, muitos dos conceitos da
norma requerem atenção humana (tomada de decisão), ou são implícitos, subjetivos
e não quantificáveis, podendo ainda remeter a outras normas normativas, o que
complica a parametrização e consequentemente a verificação automática de modelos
conforme os critérios.
Devido a isso, de um levantamento de 113 requisitos diretamente relacionados ao
projeto, o estudo mostrou que apenas cerca de 22 deles (19%) teriam potencial de ser
automatizados total ou parcialmente com o Solibri Model Checker, necessitando
inclusive, de combinações complexas de várias regras dos templates disponíveis
(SILVA; ARANTES, 2016).
Por uma ótica semelhante, Silva Júnior e Mitidiéri Filho (2015) realizaram um
levantamento acerca do uso do software BIM para arquitetura Revit, para fins de
identificação e organização dos requisitos. De um total de 93 requisitos considerados
pelos autores, 28 (30%) poderiam ser inclusos diretamente nos modelos BIM como
parâmetros compartilhados, podendo ser verificados por outras ferramentas ou
apenas explicitados por meio de tags. Os autores destacam que colocar especificações
de materiais e sistemas diretamente no modelo BIM poderia facilitar o processo de
escolha dos projetistas e auxiliar na geração de documentação consistente.
79
Com uma abordagem de organização de dados semelhante, e com o intuito de tornar
as informações de desempenho organizadas e acessíveis diretamente no modelo BIM,
Costa e Ilha (2017) propuseram a criação de uma biblioteca de componentes para
instalações hidrossanitárias, contendo parâmetros pertinentes às exigências da
Norma de Desempenho.
Um dos problemas é de que os fabricantes de tais produtos não disponibilizam
informações suficientes em seus catálogos ou páginas de internet, o que complica o
processo para o projetista que necessita escolher qual solução irá adotar (COSTA;
ILHA, 2017), e possivelmente, dificulta ainda mais para o desenvolvedor de
conteúdo como famílias de elementos BIM, que precisa trabalhar com a escassez de
dados referenciais para criar seus modelos customizados.
Costa e Ilha (2017) visitaram repositórios de modelos BIM, buscando saber se
informações de desempenho haviam sido incorporadas em elementos de hidrômetro,
bacia sanitária, chuveiro, lavatório e caixa sifonada, nesta situação, outro problema
encontrado pelos autores foi a ausência destas informações nos diversos repositórios
pesquisados.
Nardelli e Oliveira (2013) também constataram que muitos dos parâmetros
relacionados a desempenho de elementos construtivos dificilmente estão presentes
nas bibliotecas de elementos BIM, o que também limita o uso da modelagem para
fins de simulação e verificação destes aspectos, pois são informações que precisam
ser adicionadas manualmente e mesmo assim, não possuem um software ou
aplicação inserida no processo BIM que seja específica para utilizá-los efetivamente.
Os autores ressaltam que, algo que atualmente acontece em outros países é a inclusão
de parâmetros pontuais nos elementos BIM, pelos próprios fornecedores de
materiais, informações voltadas para campos específicos da indústria local, como por
exemplo: parâmetros de classificação de resistência ao fogo e propriedades
relacionadas à segurança (NARDELLI; OLIVEIRA, 2013).
No Brasil, partindo da premissa de que os fornecedores precisam conhecer e
disponibilizar as informações de desempenho, iniciativas são feitas por alguns
fabricantes como Pauluzzi, Saint-Gobain e Portobello (PAULUZZI, 2018;
PORTOBELLO, 2018; SAINT-GOBAIN, 2018), que estão realizando um esforço para
disponibilizar sua biblioteca de produtos para softwares como o Revit, para que
projetistas tenham acesso a algumas informações do comportamento esperado de
suas soluções durante a modelagem.
Contudo, a utilidade de muitos dos parâmetros colocados nos componentes ainda
precisa ser consolidada por ferramentas que efetivamente os utilizem em cálculos,
80
verificações ou geração de relatórios. Um modelo com informações que jamais serão
utilizadas, apenas aumentam o tamanho dos arquivos e não geram benefícios. É
necessário utilizar o processo BIM para colocar estas informações em um contexto e
prepará-las para serem verificadas, simuladas ou documentadas, ou correm o risco
de tornarem-se apenas mais um dado avulso, o qual não compõe o processamento
efetivo de informação.
Outro ponto é que, por mais que alguns processos de projeto possam ser
completamente automatizados com a tecnologia BIM, esta deve ser utilizada em prol
da exploração de alternativas (AISH, 2013), de modo a dar informações e suporte ao
projetista durante sua tomada de decisão, e não simplesmente realizar o trabalho por
ele, visto que muitas das informações requerem conhecimento técnico, interpretação
e julgamento, o que limita a efetividade de um code-checking em uma norma
diretamente relacionada à qualidade e escolhas de projeto.
Contemplando estas situações, neste trabalho é proposta a programação de
ferramentas visando esta integração e efetivo uso das informações para verificar e
simular cenários de desempenho. No capítulo seguinte, é apresentado o método
utilizado para direcionar o desenvolvimento de tal programação.
81
5. DESIGN SCIENCE RESEARCH
Este capítulo trata do método utilizado para a pesquisa, descrevendo conceitos
fundamentais do Design Science Research, desde a contextualização do paradigma
Design Science, alicerçado nas definições de Simon (1996), até a determinação das
etapas metodológicas e o detalhamento dos procedimentos utilizados para gerar os
produtos do trabalho. Para tal, utilizou-se como principal referência o livro Design
Science Research – A Method for Science and Technology Advancement, de Dresch,
Lacerda e Antunes Jr. (2015).
Para adoção deste método, foi realizada uma revisão bibliográfica para descrevê-lo –
apresentada nos itens 5.1 e 5.2. Então, a presente pesquisa é situada no método a
partir do item 5.3, que descreve as atividades de desenvolvimento e avaliação, bem
como as definições para cada etapa.
5.1 O paradigma Design Science
Van Aken (2004) define paradigma de pesquisa não somente como um conjunto de
hábitos científicos, mas como a combinação das perguntas realizadas, os métodos
que possibilitam respondê-las e a natureza dos produtos gerados.
Design consiste na aplicação de mudanças a um sistema, visando transformar
situações para atingir melhorias (SIMON, 1996). Enquanto que nos paradigmas das
ciências naturais e sociais o foco é voltado para a geração de conhecimento a partir de
algo que já é conhecido – por meio da compreensão de fenômenos, Design Science
busca o conhecimento acerca de sistemas artificiais, que ainda não existem (SIMON,
1996), ou ainda, métodos para desenvolver objetos e sistemas inovadores, para
modificar o existente e atingir maior performance – uma abordagem científica
prescritiva (MARCH; SMITH, 1995).
O argumento de Simon (1996) é de que, a prescrição ou o design de uma solução para
um problema também é uma forma de conhecimento, e de que conhecimento
puramente descritivo acerca do comportamento de fenômenos não é suficiente para
preencher muitas das lacunas de um tema, sendo necessário pensar na maneira como
tais aspectos deveriam ser – maneiras aprimoradas de criar, e não apenas como
atualmente são.
As pesquisas de caráter natural possuem um objetivo marcantemente descritivo,
onde exploram e descrevem seus temas para compreender e predizer fenômenos e
sua complexidade com base na observação (VAN AKEN, 2004), buscando realizar
descobertas acerca de seu comportamento e justificar suas teorias. Com uma
82
abordagem similar, ciências sociais buscam descrever, compreender e refletir sobre
as ações do ser humano, por diversas perspectivas. Tais pesquisas descritivas
também são chamadas de comportamentais (HEVNER et al., 2004) ou explanatórias
(VAN AKEN, 2004).
Nas ciências explanatórias ou descritivas, o fenômeno a ser estudado deve existir
antes de o conhecimento ser produzido, ao passo que, nas ciências exploratórias ou
prescritivas, onde o Design Science está inserido, o fenômeno deve inicialmente ser
criado artificialmente, e seu processo avaliado, para que se possa produzir o
conhecimento (SIMON, 1996).
Pela ótica do foco da pesquisa, enquanto que nas ciências naturais e sociais existe
uma ênfase na descoberta e justificação de fenômenos pela compreensão e
explanação, Design Science consiste em um paradigma para construção e avaliação de
artefatos voltados às necessidades identificadas em um cenário ou organização
(HEVNER et al., 2004), para atingir objetivos humanos de caráter prático (MARCH;
SMITH, 1995). No Design Science, o conhecimento é produto dos artefatos que
manipulam os fenômenos e não da descrição ou explicação de tais fenômenos
(VAISHNAVI; KUECHLER, 2007).
O produto da pesquisa no âmbito do Design Science também difere em relação às
pesquisas descritivas. No paradigma do Design Science, o principal interesse está na
criação destes artefatos, com a preocupação voltada para o aprimoramento de
situações práticas reais (HOLMSTRÖM; KETOKIVI; HAMERI, 2009), a melhoria da
performance no uso (VAISHNAVI; KUECHLER, 2007) e no desenvolvimento de
sistemas (MARCH; SMITH, 1995).
Quanto ao posicionamento do pesquisador no âmbito do Design Science, este não está
satisfeito apenas com explicar e predizer os fenômenos (VAN AKEN, 2004), mas sim
com moldar artificialmente situações e cenários, assumindo um papel ativo na
produção de conhecimento através da exploração do design (SIMON, 1996). O
pesquisador está interessado em desenvolver, em caráter prático e tecnológico,
prescrições para um problema que se manifesta na forma dos artefatos
(HOLMSTRÖM; KETOKIVI; HAMERI, 2009). A busca por conhecimento acadêmico
nas pesquisas descritivas coloca o pesquisador como um observador, analista ou
crítico dos fenômenos (KASANEN; LUKKA; SIITONEN, 1993) e não como um
desenvolvedor, agente ou player principal (VAN AKEN, 2004) das mudanças no meio
prático.
Pesquisa teórica produzida por acadêmicos por vezes não coincidem com os
interesses práticos, se distanciando muito das reais necessidades de comunidades e
organizações (HOLMSTRÖM; KETOKIVI; HAMERI, 2009; KASANEN; LUKKA;
83
SIITONEN, 1993). Holmström, Ketokivi e Hameri (2009) defendem que, uma
pesquisa voltada para o desenvolvimento de soluções, por meio da inserção destes
novos métodos ou artefatos, pode auxiliar na redução da lacuna entre teoria e
prática, prescrevendo maneiras de abordar problemas reais e caracterizando-se como
uma maneira de alavancar a relevância da pesquisa proposta (DRESCH; LACERDA;
ANTUNES JR., 2015).
A abordagem de pesquisa Design Science pode ser imediatamente relevante do ponto
de vista prático, em virtude de seu foco na criação de soluções inovadoras voltadas
para problemas específicos. Contudo, o desafio está em tornar tal conhecimento
relevante no ponto de vista teórico, por meio da exploração de suas contribuições
para o cenário acadêmico (HOLMSTRÖM; KETOKIVI; HAMERI, 2009).
Holmström, Ketokivi e Hameri (2009) e Van Aken (2004), afirmam que a relevância
da pesquisa pode ser aumentada com o uso complementar de características de
ambos os paradigmas, defendendo a integração das características das ciências
descritivas e prescritivas. Hevner et al. (2004) complementam tal posicionamento
ressaltando que não são abordagens mutualmente excludentes, mas sim que
possuem um grau de interdependência e sinergia. Os autores (HOLMSTRÖM;
KETOKIVI; HAMERI, 2009) exemplificam tal situação: na pesquisa
prescritiva/exploratória, novas teorias e artefatos são produzidos visando resolver
problemas específicos com base em fundamentos teóricos, ao passo que, na pesquisa
descritiva/explanatória, tais construções são verificadas em diferentes contextos,
reforçando seu mérito e apontando suas lacunas, fomentando a criação e
transformação de novos artefatos, e assim por diante. March e Smith (1995) reforçam
tal ideia ao declarar que o desenvolvimento de artefatos prescritivos pode também
auxiliar na compreensão e descrição de fenômenos por pesquisadores descritivos,
podendo inclusive servir como objeto de estudo destes.
Alguns autores (HOLMSTRÖM; KETOKIVI; HAMERI, 2009; VAN AKEN, 2004)
caracterízam as áreas de engenharia, medicina e arquitetura como áreas permeadas
pelo Design Science, devido ao fato de que são inerentemente voltadas para as
ciências de criação de situações artificiais e simuladas, onde o conhecimento ocupa
um campo intermediário entre teoria descritiva e a aplicação propriamente dita,
híbrido entre a explanação e a prescrição.
Segundo Dresch, Lacerda e Antunes Jr. (2015), pesquisadores podem avançar o
conhecimento científico ao mesmo tempo que dão suporte à resolução de problemas
de outros profissionais ou de organizações, por meio do uso de uma pesquisa
aplicada, de caráter prático, e voltada para o uso de seus resultados em situações
reais, um dos métodos inseridos no paradigma é o Design Science Research.
84
5.2 O método Design Science Research
Design Science Research é um método inserido no paradigma do Design Science para
operacionalizar uma pesquisa ou estudo que tenha como princípio prescrição de
soluções para problemas específicos (DRESCH; LACERDA; ANTUNES JR., 2015). A
missão do Design Science Research é desenvolver conhecimento válido e confiável
para a projetação de artefatos voltados à resolução de tais problemas, ou para
melhoria da performance de entidades já existentes (VAN AKEN, 2004), estendendo
limites humanos e organizacionais por meio de desenvolvimentos inovadores
(HEVNER et al., 2004; LUKKA, 2003).
No âmbito do Design Science Research, a partir do princípio de que os problemas de
profissionais possuem natureza única e específica, o ator praticante deve ser capaz de
projetar seus próprios sistemas e intervenções, com base em sua própria experiência,
criatividade e entendimento do cenário em que atua (VAN AKEN, 2004).
Descrições similares do método também são apresentadas na bibliografia sob o nome
de Pesquisa Construtiva, onde os artefatos são chamados de construções
(KASANEN; LUKKA; SIITONEN, 1993; LUKKA, 2003).
Design Science Research possui destaques em aplicações nas áreas de TI – tecnologia
de informação (MARCH; SMITH, 1995), SI – sistemas de informação (HEVNER et al.,
2004), gerenciamento e contabilidade (KASANEN; LUKKA; SIITONEN, 1993;
LUKKA, 2003), engenharia de produção (LACERDA et al., 2013) e até mesmo na
construção civil – lean construction (ROCHA et al., 2012). Em tais cenários, aparece
como uma abordagem inerentemente voltada para reduzir a lacuna entre prática
profissional e pesquisa (HOLMSTRÖM; KETOKIVI; HAMERI, 2009; KASANEN;
LUKKA; SIITONEN, 1993; LUKKA, 2003).
A abordagem construtiva significa resolver problemas por meio da construção de
modelos, diagramas, planos e organização – aparatos voltados para a prescrição de
soluções para problemas explícitos e práticos (LUKKA, 2003). Como possíveis
exemplos de artefatos resultantes de uma pesquisa construtiva estão os softwares,
ferramentas e sistemas de informação (HEVNER et al., 2004), bem como algoritmos
matemáticos, inteligência artificial e até mesmo produtos comerciais (KASANEN;
LUKKA; SIITONEN, 1993). Contudo, é necessário que tais artefatos tenham forte
relação com conhecimento teórico da área onde estão inseridos e potencial de
contribuição acadêmica (HOLMSTRÖM; KETOKIVI; HAMERI, 2009). Tal
posicionamento é reforçado por Hevner et al. (2004), que afirmam que artefatos são
por vezes objetos de estudo das pesquisas descritivas e, portanto, necessitam ter um
vínculo e fundamentação com conhecimento teórico (HEVNER et al., 2004).
85
De acordo com Dresch, Lacerda e Antunes Jr. (2015), em relação à abordagem do
método científico do Design Science Research, possui momentos de caráter indutivo,
dedutivo ou abdutivo ao longo de suas etapas (detalhadas no item 5.3.4). Enquanto a
abordagem indutiva determina leis e teorias a partir de fatos conhecidos por meio de
observação dos fenômenos (de onde vêm), a abordagem dedutiva propõe explicações
e predições quanto ao comportamento de outros fenômenos com base em tais leis e
teorias levantadas (como devem ser). Por outra ótica, a abordagem abdutiva consiste
em estudar fatos e propor teorias para explicá-los. É o processo de criação de
hipóteses acerca de um fenômeno ou situação (sugestão de como podem ser). O
método abdutivo se faz necessário quando o pesquisador busca elencar possíveis
soluções para resolver o problema que está sendo estudado (DRESCH; LACERDA;
ANTUNES JR., 2015). Na presente pesquisa, é utilizado o método indutivo – para a
caracterização do fenômeno estudado, e abdutivo – para o levantamento de
alternativas para compreensão do mesmo.
Para Dresch, Lacerda e Antunes Jr. (2015), Design Science Research como um método
difere do estudo de caso e da pesquisa-ação tanto no paradigma de pesquisa (pois
está no Design Science e não no Natural/Social Sciences), quanto nos objetivos
(prescritivos por meio dos artefatos e não descritivos), modo de avaliação dos
resultados (aplicações, simulações e experimentos ao invés de comparações), papel
do pesquisador (construtor/avaliador ao invés de observador), potencial de
generalização do conhecimento, base empírica e entre outros aspectos.
Em relação aos objetivos de pesquisas com o método Design Science Research, estes
são direcionados ao processo de criação dos artefatos (DRESCH; LACERDA;
ANTUNES JR., 2015; MARCH; SMITH, 1995), bem como para investigar o
comportamento do artefato desenvolvido por meio de técnicas de avaliação
(HEVNER et al., 2004).
Diante de tais colocações, se faz necessária a elucidação do conceito de artefatos,
rigor e relevância da pesquisa, e generalização para classes de problemas. A
justificativa e alinhamento de tais conceitos com o presente trabalho são
apresentados a seguir, conforme cada título.
5.2.1 Artefatos
Artefatos (MARCH; SMITH, 1995), também interpretados como construções
(KASANEN; LUKKA; SIITONEN, 1993) ou soluções práticas (HOLMSTRÖM;
KETOKIVI; HAMERI, 2009) são o elemento central e principal produto do método,
são contribuições de caráter prático, inovador (LUKKA, 2003) e tecnológico, que
86
visam atender um propósito específico, tendo seu caráter e ambiente definidos, bem
como seus mecanismos de avaliação.
March e Smith (1995) apontam que os produtos do Design Science Research são
classificados em quatro tipos: (1) Construtos, conceituações acerca do domínio do
problema e de suas soluções; (2) Modelos, conjunto de proposições ou afirmações de
caráter descritivo que demonstram relações entre construtos; (3) Método, conjunto de
passos ou diretrizes usadas para explicitar a realização de uma tarefa; e (4)
Instanciação ou implementação, a realização do artefato em seu ambiente,
operacionalizando construtos, modelos e métodos.
Dresch, Lacerda e Antunes Jr. (2015) sugerem um quinto tipo de artefato chamado
Design Propositions: são as contribuições teóricas, na forma de generalização do
conhecimento para a classe de problema, onde o conhecimento sobre a criação de um
conjunto de soluções é discutido acerca de sua possibilidade de aplicação em muitas
outras situações similares, desde que as particularidades de tais situações sejam
respeitadas.
Conceitos similares são apresentados por Van Aken (2004), que descreve Regras
Tecnológicas como produtos típicos do paradigma Design Science, parcelas de
conhecimento geral que vinculam um artefato com um resultado desejado em
determinado campo de aplicação, também necessitando ser avaliadas, como os
outros artefatos.
Diante de tais considerações, é necessário pontuar as instanciações. Embora
Construtos e Modelos estejam intrinsecamente envolvidos pela abordagem utilizada
por meio da introdução, revisão de bibliografia, métodos e discussões, o foco
metodológico se dará nas instanciações (ou implementações), apresentadas a partir
do Capítulo 6 – Plug-ins desenvolvidos. Alinhando com as considerações de March e
Smith (1995), as instanciações por vezes podem preceder a completa articulação do
artefato principal – que pode vir na forma de Construtos, Modelos e/ou Métodos,
pois são uma maneira de operacionalizar tais classes de artefatos.
A partir desta definição, ao passo em que as instanciações representam o artefato
realizado, interpreta-se que o artefato central deste trabalho é do tipo Método, pois
representa uma resposta ao problema inicialmente delimitado, apresentando uma
prescrição sobre como desenvolver ferramentas, suportado pela evidência
experimental destas – as instanciações na forma de plug-ins desenvolvidos para os
problemas específicos.
Para Lacerda et al. (2013, p. 8), "as instanciações podem se referir a um determinado
artefato ou à articulação de diversos artefatos para a produção de um resultado em
87
um contexto específico” – no caso do presente trabalho, dentro do cenário de
desenvolvimento de ferramentas de programação para tomada de decisão durante o
projeto arquitetônico, a criação de ferramentas voltadas para o atendimento à Norma
de Desempenho Brasileira. Embora os plug-ins não sejam o artefato principal do
trabalho, mas sim experimentos para compreender melhor as dificuldades do
processo de criação de ferramentas, interpreta-se que são fundamentais para
consolidação do artefato Método – as diretrizes ou guidelines, apresentadas no
Capítulo 8 – Conclusões.
Instanciações (ou implementações) demonstram a viabilidade e efetividade das
artefatos do tipo Método por meio da aplicação prática e instrumental destes, bem
como na viabilidade dos processos empregados na construção do artefato (HEVNER
et al., 2004; MARCH; SMITH, 1995). Isto têm como resultado ferramentas funcionais
que podem ser avaliadas e estudadas para o avanço no âmbito das teorias, podendo
ser utilizadas para compreender um cenário ou ambiente (MARCH; SMITH, 1995).
Lukka (2003) defende que o material empírico resultante da pesquisa tem potencial
de interação com tais teorias em seus diversos níveis – desde a ilustração ou teste de
alternativas até o refinamento ou criação de novas proposições. Artefatos também
podem alavancar a criação de outras ferramentas por meio do aprendizado de
soluções anteriores, não sendo isentos das leis naturais ou das colocações de teorias
descritivas já existentes, sendo sujeitos ao rigor e relevância nos seus processos
(HEVNER et al., 2004).
5.2.2 Rigor e Relevância
March e Smith (1995) autores da área de tecnologia de informação, destacam que, por
vezes, pesquisas voltadas para o desenvolvimento e melhoria de sistemas podem ter
maior relevância profissional que abordagens científicas que apenas tentam entender
e descrever tais construções.
Contudo, Holmström, Ketokivi e Hameri (2009) ressaltam que, embora soluções
práticas advindas da pesquisa possam ter resultados impressionantes e louváveis
quando auxiliam empresas ou profissionais a economizar capital e melhorar seus
processos internos, o vínculo com o conhecimento já estabelecido não pode ser
abandonado, visto que a pesquisa propriamente dita não deve ser uma consultoria e
sim uma forma de produzir conhecimento: “contribuições teóricas não são
mensuradas em dólares, são mensuradas em termos da visão inovadora e
compreensão que oferecem” (tradução nossa, HOLMSTRÖM; KETOKIVI; HAMERI,
2009).
88
Contudo, para que uma solução gerada seja satisfatória para o cenário acadêmico e
relevante para o cenário profissional, ela deve ter impacto tanto no conhecimento
teórico por meio de suas contribuições embasadas no rigor, quanto na prática por
meio da sua efetividade nas situações reais (DRESCH; LACERDA; ANTUNES JR.,
2015).
Além disso, rigor e relevância são necessários para reduzir a lacuna entre teoria e
prática do paradigma de pesquisa Design Science (MARCH; SMITH, 1995). Para isso,
a aplicação de Design Science Research deve seguir procedimentos adequados para
manter a confiabilidade dos resultados de pesquisa (HEVNER et al., 2004).
Os autores (HEVNER et al., 2004) propõem uma série de requisitos gerais para o
andamento de uma pesquisa utilizando o método Design Science Research: (1) criação
de um artefato inovador; (2) presença de um problema específico e relevante; (3)
avaliação da utilidade, qualidade e eficácia do artefato; (4) contribuições teóricas
claras e relevantes; (5) rigor científico no desenvolvimento e avaliação; (6) processos e
ambiente de pesquisa definidos; e (7) comunicação da pesquisa para profissionais e
acadêmicos.
Por meio da presente pesquisa, busca-se justificar o antendimento de tais requisitos
através da: (1) criação de plug-ins para software BIM; (2) o tema específico da
resolução de problemas ligados à Norma de Desempenho; (3) criação de mecanismos
de avaliação e feedback; (4) reflexões e estabelecimento de vínculo teórico com o
cenário descrito; (5) uso de etapas metodológicas embasadas em bibliografia; (6)
compreensão do tema geral – projetista programador e competências emergentes; e
(7) submissões de artigos em periódicos e congressos de destaque.
Por uma ótica similar, Lukka (2003) aponta alguns critérios que caracterizam uma
pesquisa como construtiva: (1) a presença de um problema real; (2) a produção de
uma inovação voltada para a resolução de tal problema; (3) o teste da aplicabilidade
prática de tal solução – avaliação; (4) aprendizado experiencial por meio do
envolvimento do pesquisador com o tema; (5) vínculo com conhecimento teórico; e
(6) reflexão acerca das descobertas empíricas e seu impacto na teoria.
Em relação ao andamento e maturidade de pesquisa, Holmström, Ketokivi e Hameri
(2009) detalham em seu trabalho quatro fases1 de uma pesquisa com Design Science
Research, de modo a manter o rigor e relevância, enfatizando o alcance do
1 Tais fases não são as etapas metodológicas ou sequência de procedimentos do método, mas sim uma
classificação acerca do alcance da pesquisa em termos de definição de teorias.
89
desenvolvimento cognitivo e teórico ao longo do tempo, de maneira ampla. São elas:
(A) Incubação da solução: onde ocorre a exploração de problemas e o
desenvolvimento inicial de uma solução por abdução, sendo esta detalhada
suficientemente para ser aplicada em um cenário; (B) Refinamento da solução: onde
se determina o que funciona e não funciona, no âmbito da solução, por meio de
melhorias, implementação ou avaliação, resultando também em padrões de design
que necessitam ser avaliados em outros cenários; (C) Explanação I – Teoria
Substantiva: que consiste na generalização das descobertas na forma de contribuição
teórica, agindo como uma teoria de escopo limitado (mid-range) a um determinado
contexto (o ambiente onde o artefato foi criado), nesta etapa, o pesquisador justifica a
solução específica e defende sua utilidade teórica pelo sua introdução em outros
contextos; (D) Explanação II – Teoria Formal: onde a pesquisa atinge níveis de
generalização e abstração teórica amplos, com seu significado incorporado na lógica
da própria teoria, sendo afastado da necessidade de comprovação empírica de suas
soluções.
Em relação às fases de desenvolvimento de pesquisa com Design Science Research
apontadas por Holmström, Ketokivi e Hameri (2009), para o presente trabalho, as
etapas alcançadas se estendem até (A) Incubação da solução, e parcialmente (B)
Refinamento da solução, devido ao fato de que, embora a exploração e
desenvolvimento inicial tenham sido feitos, e os experimentos avaliados, estes não
foram submetidos à avaliação em outros contextos além do cenário específico
escolhido. Há, porém, contribuição teórica do estudo por meio do desenvolvimento
de prescrição na forma de diretrizes para o desenvolvimento de ferramentas, bem
como pela exploração e generalização da classe de problemas (item 5.2.3) para outros
cenários, o que inclui alguns dos conceitos discutidos na fase (C) Explanação I –
Teoria Substantiva.
Conforme os autores (HOLMSTRÖM; KETOKIVI; HAMERI, 2009), perseguir o nível
de desenvolvimento na fase (C) é de interesse para uma pesquisa em Design Science
Research devido ao fato de que possibilita fortalecer os vínculos teóricos a partir das
soluções práticas desenvolvidas. No presente caso, isto significa utilizar os
experimentos desenvolvidos (plug-ins) para compreender o cenário descrito no
capítulo introdutório e apresentar um artefato na forma de diretrizes de
desenvolvimento de ferramentas, bem como o posicionamento crítico quanto às
atividades.
90
5.2.3 Classes de problemas e generalização
Artefatos gerados para responder a um problema são únicos e específicos em seu
contexto isolado, contudo, as origens do problema abordado possuem raízes mais
amplas. No universo de problemas a serem solucionados, existem características
semelhantes entre eles, que permitem a organização de tais similaridades em uma
Classe de Problema – o que permite a generalização de soluções em contextos
diferentes, mas relacionados (DRESCH; LACERDA; ANTUNES JR., 2015).
Lacerda et al. (2013, p. 7) definem um conceito acerca das classes de problemas: "a
organização de um conjunto de problemas, práticos ou teóricos, que contenha
artefatos avaliados, ou não, úteis para a ação nas organizações”. Tais classes de
problemas possuem o propósito de tornar os artefatos e suas soluções não apenas
respostas pontuais ou ocasionais para os problemas específicos em contextos
particulares (DRESCH; LACERDA; ANTUNES JR., 2015; LACERDA et al., 2013).
Kasanen, Lukka e Siitonen (1993) reforçam tal conceito, destacando que o material da
pesquisa deve ter um grau de generalização, ou seja, a solução funcional produzida
para o problema gerencial é passiva de reaplicação em cenários ou organizações de
mesmo tipo. Os autores complementam a importância do tópico tomando esta
questão por outra perspectiva, argumentando que, “após projetar uma construção
gerencial que funciona, pode-se começar a considerar quais são as características
mais gerais que são reveladas pela criação de uma nova realidade” (tradução nossa,
KASANEN; LUKKA; SIITONEN, 1993, p. 260).
Após a resolução de casos específicos, o pesquisador pode gerar conhecimentos que
podem ser transferidos a estes domínios similares com base na reflexão sobre o
aprendizado e análise dos casos (VAN AKEN, 2004), propagando uma contribuição
teórica não apenas específica ao problema mas para sua classe de problemas.
Conforme Dresch, Lacerda e Antunes Jr. (2015), as classes de problemas são
idenficadas por meio da revisão bibliográfica e definição dos possíveis artefatos
existentes no cenário de pesquisa, acerca do tema a qual se pretende desenvolver as
soluções. Em relação à denominação da classe de problemas do presente trabalho, foi
classificada como o Suporte à Tomada de Decisão, com base nos levantamentos
bibliográficos da introdução e dos trabalhos relacionados apresentados nas temáticas
específicas dos Capítulos 2, 3 e 4.
Em relação à generalização para a classe de problema do trabalho, foi delineado que
permite que o processo de desenvolvimento e avaliação dos artefatos (plug-ins)
possa ser replicado em outros temas além da Norma de Desempenho, ou seja, o
desenvolvimento de plug-ins ou ferramentas de apoio à decisão pode ter sua
91
aplicação generalizável se a maneira de responder o problema é devidamente
explicitada e possua mecanismos de avaliação definidos.
Diante dos fundamentos apresentados nos itens anteriores deste capítulo, justifica-se
a adoção do Design Science Research como método para este trabalho por uma série de
razões: devido ao enquadramento com o paradigma de pesquisa, com foco na
prescrição de uma solução e não apenas na ilustração do fenômeno; devido ao papel
do pesquisador – que deixa de ser observador do desconhecido e passa a ser
explorador; devido aos produtos da pesquisa, onde se busca criação de um artefato
voltado para a melhoria de processos em contextos específicos – diretrizes para o
desenvolvimento de plug-ins, tomando como evidência instanciações voltadas à
Norma de Desempenho; e principalmente, devido ao fato de que tal método
possibilita ter relevância tanto no cenário acadêmico – por meio das contribuições
teóricas, generalizações para classe de problemas e reflexões acerca dos avanços
tecnológicos na AEC, como no cenário profissional – por meio do desenvolvimento e
exploração de métodos e ferramentas voltadas para soluções práticas.
5.3 Etapas da pesquisa
Pela perspectiva de March e Smith (1995), Design Science Research pode ser dividido
em duas macro etapas: (1) Construção, onde se desenvolve os artefatos para
demonstrar a viabilidade de atuação deste como uma solução ao problema proposto
(o artefato funciona?); e (2) Avaliação, onde o progresso alcançado deve ser
mensurado (quão bem o artefato funciona?) a partir da elaboração de métricas
específicas que verifiquem por que e como o artefato se comporta em seu ambiente
ou contexto.
Por uma ótica mais detalhada, Kasanen, Lukka e Siitonen (1993) e Lukka (2003)
relatam que a abordagem construtiva possui etapas que variam de caso a caso.
Contudo, os autores direcionam algumas etapas necessárias: (1) encontrar um
problema de relevância prática, mas que também possui potencial de pesquisa; (2)
obter compreensão do tópico; (3) inovar ou construir uma idéia de solução; (4)
demonstrar que tal solução funciona; (5) mostrar as conexões teóricas e contribuição
de pesquisa do conceito da solução; (6) examinar o escopo de aplicabilidade da
solução.
Sob a luz de tais conceitos, Dresch, Lacerda e Antunes Jr. (2015) sugerem um
detalhamento maior das etapas de condução do Design Science Research, etapas que
são seguidas no andamento da presente pesquisa, conforme delineado na Figura 35 e
então discutido na sequência.
92
Figura 35 - Etapas da pesquisa
Fonte: adaptado de Dresch, Lacerda e Antunes Jr. (2015).
1ª Etapa – Identificação do problema: inicia-se a pesquisa evidenciando a situação
problemática, descrevendo o cenário que se pretende prescrever as alternativas de
solução, caracterizando as principais contribuições e os atores que se interessam pelo
fenômeno. Os resultados desta etapa estão permeados pelo capítulo de Introdução
do presente trabalho.
2ª e 3ª Etapas – Conscientização do problema e Revisão Bibliográfica: nestas etapas
ocorre a compreensão aprofundada do problema a partir da busca pelas informações
de temáticas relacionadas. Embora Dresch, Lacerda e Antunes Jr. (2015) sugiram o
93
uso de uma revisão sistemática de bibliografia, optou-se por uma revisão
aprofundada nos tópicos principais do trabalho – BIM e Programação em softwares
BIM, bem como o tópico específico pelo qual é pretendido abordar o problema –
Desempenho das Edificações. Nesta etapa já são pensadas maneiras de como é
possível abordar o problema por meio de aplicações específicas, considerando
também as funções dos artefatos, por meio do entendimento do cenário. Tais
conceitos foram abordados nos Capítulos 2, 3 e 4 do presente trabalho.
4ª Etapa – Identificação dos artefatos e configuração da classe de problemas:
consiste na busca por artefatos já existentes e a investigação acerca do tipo de
problema que buscam resolver, bem como suas limitações. Devido ao fato de que o
tema abordado é de grande amplitude e com uma variedade de possíveis aplicações,
é necessário delimitar a classe de problemas. Como maneira de emular o cenário
introdutório descrito e explicitar como ele pode ocorrer, escolheu-se a Norma de
Desempenho como cenário específico, por sua relevância no âmbito dos projetos
(descrita no Capítulo 4). Além disso, as instanciações identificadas na forma de plug-
ins e extensões para softwares BIM foram classificadas e agrupados por uma
pesquisa preliminar (survey mencionado no capítulo introdutório, presente no
Apêndice A e B), tal abordagem permitiu elencar possíveis soluções para a classe de
problema – Suporte à Tomada de Decisão, no âmbito da especificação escolhida – o
atendimento à Norma de Desempenho em projetos. Considerações quanto às
instanciações e a importância da classe de problemas foram feitas nos items 5.2.1 e
5.2.3 do presente capítulo.
5ª Etapa – Proposição dos artefatos para resolver problemas específicos: processo
exploratório e criativo que utiliza da abdução para elencar soluções consideradas
satisfatórias. Nesta etapa, dentre as possíveis alternativas, no âmbito do
desenvolvimento das ferramentas para atendimento à norma, definiu-se, de acordo
com a descrição dos problemas específicos nos items 6.1 e 6.2, pela criação
experimental de dois plug-ins para um software BIM, com focos direcionados com
base nos resultados do survey. Estes dois experimentos servem como uma evidência
para construção das diretrizes de desenvolvimento e constituem-se, portanto, em
artefatos na forma de instanciações destas diretrizes.
6ª Etapa – Projeto dos artefatos: nesta etapa, dos artefatos elencados nas fases
anteriores, são definidas as métricas, premissas e critérios para aceitação do nível de
desenvolvimento – que tipo de solução é satisfatória, bem como suas limitações e
relações com o ambiente externo – de que maneira os artefatos solucionam os
problemas específicos e como poderão emular o cenário descrito ao início do
94
trabalho. Justifica-se a escolha das ferramentas para desenvolvê-las (item 5.3.1) e
explicita-se sua composição (itens 6.1.1 e 6.2.1).
7ª Etapa – Desenvolvimento dos artefatos: consiste na criação das ferramentas
conforme o que foi definido em seus projetos, pelo meio escolhido – programação
(item 5.3.1), de modo a atingir a funcionalidade das instanciações em um estado
piloto. Os resultados do desenvolvimento das instanciações estão nos itens 6.1.2 e
6.2.2.
8ª Etapa – Avaliação dos artefatos: com os artefatos do tipo instanciação
funcionando, é necessário construir um mecanismo de avaliação e explicitar a forma
como podem ser testados, de acordo com métodos (item 5.3.2), de modo a ter feedback
qualitativo acerca de suas características (utilidade, funcionalidade, usabilidade) em
relação à solução do problema específico. Os resultados da avaliação dos plug-ins
estão apresentados ao longo do Capítulo 7 deste trabalho.
9ª, 10ª e 11ª Etapas – Explicitação das aprendizagens; Conclusões; Generalização
para classe de problemas: neste grupo de etapas é feita uma contribuição teórica
para o cenário inicialmente descrito por meio da reflexão e síntese das experiências,
explicitando como os resultados atingidos podem servir de referência em outros
trabalhos e em que outros cenários a abordagem pode ser replicada com base nos
aspectos gerais das ferramentas desenvolvidas – justificativa para a classe de
problemas. Nesta etapa também é apresentado o artefato do tipo Método – as
diretrizes de desenvolvimento de ferramentas, a partir da experiência de criação e
avaliação de suas instanciações. Tais colocações estão localizadas na seção final do
trabalho, no Capítulo 8.
12ª Etapa – Comunicação dos resultados: esta etapa é atendida pela apresentação da
pesquisa desenvolvida por meio das publicações em periódicos e congressos
relacionados aos temas abordados, sendo continuada também em trabalhos futuros
que sigam a abordagem.
Um aspecto adicional pontuado por Simon (1996) é de que a natureza do paradigma
Design Science é dotada de ciclos de desenvolvimento, onde se gera alternativas de
design, e as testa conforme os requisitos inicialmente impostos ou limitações
encontradas, retornando para uma nova geração de artefatos, e assim por diante.
Outros autores (DRESCH; LACERDA; ANTUNES JR., 2015; VAISHNAVI;
KUECHLER, 2007) ressaltam tais ciclos no Design Science Research, destacando que é
possível retornar a uma etapa metodológica anterior para reformular a questão
problema ou aprimorar os artefatos. Devido ao fator do tempo para desenvolvimento
95
desta dissertação, os artefatos estão no ciclo piloto, e tais aspectos poderão apenas ser
contemplados em produções acadêmicas futuras.
Devido ao fato de que os produtos resultantes de muitas das etapas estão inseridos
na forma de discussões e considerações ao longo do texto do trabalho, o
detalhamento metodológico a seguir tem ênfase no alcance dos produtos das etapas
(7) Desenvolvimento dos artefatos e (8) Avaliação dos artefatos.
5.3.1 Definições para o desenvolvimento dos artefatos
O presente tópico visa dar detalhes adicionais para metodologia do processo
essencialmente criativo (DRESCH; LACERDA; ANTUNES JR., 2015) de
desenvolvimento dos artefatos (presente nas etapas 5, 6 e 7). Como pontuado
anteriormente (item 5.2.1), com base nos tipos de contribuição de March e Smith
(1995), os artefatos desenvolvidos neste trabalho são do tipo instanciação, pois
remetem a uma articulação da questão problema apresentada no início do trabalho,
por meio de uma abordagem específica – o atendimento à Norma de Desempenho,
com uma classe de problema definida – a tomada de decisão de projetistas.
Devido ao fato de que duas ferramentas foram desenvolvidas, para compreensão
mais adequada de etapas do método de desenvolvimento e para facilitar a leitura
deste trabalho, partes do método foram propositalmente reestruturadas para o início
do Capítulo 6. Assim, os procedimentos relativos à identificação do problema
específico em cada instância (desempenho acústico e lumínico), bem como as
definições do projeto de cada plug-in (fluxogramas, referências da norma e
definições de funcionamento) ficam organizadas separadamente e seguidas pelos
respectivos resultados, referentes aos procedimentos para cada plug-in.
Em relação à plataforma e ferramentas nas quais foram programados os plug-ins,
decidiu-se pelo software BIM para arquitetura Autodesk Revit, versão 2018.3,
utilizando a extensão de programação visual Dynamo, versão 1.3.2.2480. Em relação
aos pacotes componentes customizados do Dynamo, foram utilizados os seguintes:
• archi-lab.net (versão 2018.0.8)
• bimorphNodes (versão 2.2.60)
• Clockwork for Dynamo 1.x (versão 1.31.1)
• Data-Shapes (versão 2018.1.20)
• Honeybee (versão 0.1.7)
• Ladybug (versão 0.2.0)
• Rhythm (versão 2018.3.21)
• spring nodes (versão 132.2.3)
• SteamNodes (versão 1.2.4)
96
• Prorubim Dyno (versão 1.0.0)
Além disso, foi utilizada a extensão Dyno Browser, versão 0.6.6.1613 para criação de
interfaces e pré-configuração de inputs, bem como o uso da linguagem de
programação textual Python para refinamento e otimização do código (PYTHON,
2018).
A decisão pela extensão Dynamo foi tomada com base em alguns motivos:
primeiramente devido à maior facilidade de aprendizado das ferramentas baseadas
em VPL quando comparadas a TPL em relação ao tempo disponível para o trabalho.
Além disso, pela identificação das comunidades ativas de usuários que programam,
discutem e submetem suas soluções próprias aos repositórios e fóruns, que
possibilitam ao pesquisador estar inserido ativamente no cenário descrito no capítulo
introdutório, o por consequência permite relacionar a pesquisa com o cenário de
mudanças e inovações.
Em relação ao desenvolvimento das instanciações, conforme Dresch, Lacerda e
Antunes Jr. (2015), durante tal processo, o pesquisador pode definir as Heurísticas de
Construção, organizações internas do artefato, definidas como os requisitos para o
funcionamento adequado do mesmo, levando em conta o ambiente externo. Nesta
etapa, mecanismos internos, métricas, premissas e critérios para satisfação da solução
devem ser expostos. No caso deste trabalho, tais conceitos são apresentados a partir
do Capítulo 6 por esquemas, equações, tabelas e fluxogramas (organização interna),
de modo a direcionar as funções de cada uma das ferramentas desenvolvidas para
atender a Norma de Desempenho (ambiente externo).
Dresch, Lacerda e Antunes Jr. (2015) também sintetizam o processo de construção de
artefatos pela ótica de suas propriedades ou camadas de desenvolvimento, são elas:
(1) Viabilidade, onde se verifica se o que foi delimitado como prescrição para o
problema específico pode realmente ser feito com os meios disponíveis,
considerando os requisitos para sua implementação inicial; (2) Valor, que consiste em
explicitar por que o artefato é benéfico para seus usuários, bem como justificar por
que tal artefato foi escolhido para ser criado e não outros, no âmbito do tema
específico; (3) Representação, onde se discute quais as maneiras apropriadas de
comunicar os conceitos e funções do artefato para seus possíveis usuários
(interfaces); e (4) Construção, onde o processo é formalizado, e que neste trabalho,
consiste no uso das ferramentas (Revit, Dynamo) e técnicas (programação) para
produzir os artefatos em seu estado piloto e torná-los funcionais, passíveis de serem
avaliados.
Em relação ao cenário de problemas oriundos dos processos de projeto tradicionais e
da falta de adequação de componentes BIM a normativas brasileiras, destaca-se a
97
lacuna de plug-ins voltados para análises de performance das edificações (SILVA et
al., 2017a), bem como a desconectividade de tais informações a dados de referência
para projetistas, sendo estas algumas das motivações para o desenvolvimento dos
artefatos direcionados para esta temática.
Buscou-se identificar alguns problemas característicos do processo de projeto, que
sejam relacionados ao atendimento à Norma de Desempenho. Para isso, alternativas
baseadas na programação de funcionalidades em plataformas BIM foram levantadas
– desenvolvimento de plug-ins, de modo a possibilitar a qualificação dos processos
de projeto voltados para o desempenho, conforme a Figura 36.
Figura 36 - Esquema básico de desenvolvimento de plug-ins
Fonte: Autor (2018).
A plataforma Autodesk Revit foi escolhida como o software BIM a ser programado
devido a sua comunidade de usuários já estabelecida e suas possibilidades de
customização (AUTODESK, 2017c). Além disso, como muitas das avaliações de
desempenho precisam ser comprovadas por meio de projetos documentados, a
iniciativa desta etapa metodológica parte da premissa de que informações dos
modelos BIM possam ser manipuladas por programação para verificar, calcular ou
simular o desempenho de sistemas construtivos em uma edificação, diretamente do
ambiente de arquitetura BIM pelo Revit.
Dynamo foi escolhido como a maneira de desenvolver os plug-ins, pois possibilita a
manipulação de dados do modelo de arquitetura, bem como a automatização de
processos onde haja a necessidade de interações e repetição, que utilize parâmetros
compartilhados ou que envolvam design paramétrico de modo geral.
Contudo, é necessário definir critérios de problemas de projeto que utilizem tais
potenciais de programação. Com isso, situações de projeto que facilmente podem ser
resolvidas no próprio Revit, por cálculos simples, por planilhas no Excel ou que já
possuam um software próprio não são desejadas. São almejadas situações onde os
plug-ins realizem tarefas que dificilmente possam ser realizadas utilizando apenas
98
funções básicas do Revit, que utilizem a complexidade de dados de famílias e
encadeamento lógico, ou ainda, que proporcionem funcionalidades interativas com o
usuário, que possibilitem auxiliar nos processos de escolha de soluções tecnológicas
de sistemas construtivos enquanto o projetista realiza a modelagem de arquitetura –
possibilitanto ter feedback acerca do desempenho da edificação já nas etapas iniciais.
Desta maneira, o funcionamento geral desejado (Figura 37) baseia-se no uso da
modelagem de arquitetura para extração de informações geométricas e parâmetros,
dados que são manipulados internamente por meio da extensão Dynamo e seus
pacotes de funções, na forma de rotinas de programação. Então, após o
processamento, informações relativas a cálculos, verificações e simulações,
relacionadas às estimativas de desempenho da edificação, são apresentadas ao
usuário, por meio de listas, tabelas, e filtros de vista de elementos BIM, podendo ser
utilizados em vistas ou pranchas do Revit para gerar documentação de desempenho
da edificação.
Tal processo precisa ser dado por meio de uma interface de fácil uso, de modo que
projetistas com conhecimento acerca da NBR 15.575 possam usar os plug-ins para
alavancar seus processos de projeto. A intermediação entre as rotinas de
programação e a inserção de inputs pelo usuário é dada no organizador de rotinas
Dyno Browser, aliado ao pacote de funções de interface Data-Shapes. Assim, um
segundo usuário não necessita abrir a extensão Dynamo, ou ter conhecimentos
avançados de programação, para executar as análises de desempenho.
Figura 37 - Esquema de funcionamento geral dos plug-ins
Fonte: Autor (2018).
99
Dois plug-ins foram propostos: um para a estimativa do desempenho acústico de
vedações verticais (apresentado no item 6.1 deste trabalho), e outro para a estimativa
de níveis de iluminância natural no interior de ambientes (item 6.2). Ambas as
ferramentas são ligadas a dados de referência da NBR 15.575 para suas interações,
resgatando as premissas de melhoria do processo de tomada de decisões de projeto
voltadas para a performance das edificações.
5.3.2 Definições para a avaliação de artefatos
Este tópico tem por objetivo detalhar o método de avaliação das ferramentas
desenvolvidas. Kasanen, Lukka e Siitonen (1993) afirmam que os mecanismos de
avaliação são necessários para que as soluções propostas possam ser colocadas em
prática e para que sua relevância seja explicitada e demonstrada por sua
implementação, através de métodos de avaliação. A importância da etapa de
avaliação está no fato de que esta resultar na identificação de pontos fracos nas
características do artefato, tipicamente direcionando esforços futuros de pesquisa
(HEVNER et al., 2004).
Devido ao fato de que duas ferramentas foram avaliadas, para compreensão mais
adequada de etapas do método de avaliação e para facilitar a leitura deste trabalho,
partes do método foram propositalmente reestruturadas para o início do Capítulo 7.
Isto se deve ao fato de que partes dos resultados de desenvolvimento precisam ser
apresentadas ao leitor antes da etapa de avaliação para sua adequada compreensão.
Assim, os procedimentos relativos à estruturação de questões em cada instância
(desempenho acústico e lumínico), ficam organizadas seguidas pelos respectivos
resultados de avaliação, referentes aos procedimentos para cada plug-in.
Hevner et al. (2004) e March e Smith (1995), afirmam que a avaliação geralmente tem
caráter empírico, e pode contemplar aspectos como completude, utilidade,
funcionalidade, simplicidade, eficiência, compreensão, precisão, desempenho,
confiabilidade e usabilidade do artefato desenvolvido, entre outros.
Conforme Dresch, Lacerda e Antunes Jr. (2015), durante a experimentação de
artefatos, ocorre a definição das Heurísticas de Contingência, que define limitações
do artefato, suas condições de uso e situações em que será útil – caracterização do
ambiente externo do artefato, ou ainda, contexto no qual pode ser aplicado. Tais
considerações são feitas no Capítulo 7, para os dois artefatos desenvolvidos.
Hevner et al. (2004) realizaram um levantamento acerca de alguns métodos de
avaliação de artefatos. Para este trabalho, propõe-se a forma de avaliação Black Box,
descrito por Khan (2011) como testes feitos por terceiros sem conhecimento da
100
estruturação interna da ferramenta, de modo a verificar seus aspectos de
funcionalidade pelo uso.
Em relação ao Black Box, pela perspectiva do desenvolvimento de programas, Khan
(2011) aponta que, diferentemente da análise de estrutura interna de ferramentas, a
abordagem permite ao desenvolvedor ter informações a partir de um terceiro sem
conhecimento acerca de como a ferramenta foi programada, conhecendo apenas os
Inputs necessários e Outputs esperados. Devido a estas características, esta
abordagem permite menor tendenciosidade em relação ao avaliador da ferramenta.
Buscando-se obter feedback qualitativo de profissionais, Khan (2011) descreve uma
série de possíveis procedimentos para realização dos testes Black Box. Dentre os
quais, foram levados em consideração, e adaptados para este trabalho o Cause-Effect
Graph – que consiste no estabelecimento de relações esperadas entre estes Inputs
necessários e Outputs desejados, possibilitando avaliar se o comportamento da
ferramenta é equivalente ao projetado; e o State Transitioning Testing – que consiste na
exploração livre da interface por meio do uso de funções do programa em ordens
diversas, coerentes e incoerentes, podendo ocasionar situações não previstas (bugs e
inconveniências) durante o uso das ferramentas (KHAN, 2011).
Em relação à realização prática da avaliação Black Box, definiu-se que profissionais
são convidados individualmente para uma sessão de demonstração de duração de
aproximadamente 1 hora. Os profissionais são apresentados aos plug-ins, com
descrição das funcionalidades propostas e premissas de como estes possibilitam
flexibilizar o processo de tomada de decisão nos projetos. As funções dos plug-ins
são então detalhadas pelo apresentador em relação a seus Inputs necessários e
Outputs esperados, na sequência sendo executadas em projetos exemplo, onde
modificações podem ser feitas nos parâmetros geométricos e de materiais e seu
impacto avaliado na composição dos sistemas construtivos.
Ao final da etapa de demonstração é feita uma entrevista estruturada por um roteiro
ou questionário, onde o profissional responde questões acerca do funcionamento
esperado do programa em cada uma de suas funcionalidades, sugere alterações e
aponta erros encontrados. Esta etapa é registrada pela gravação em áudio da
entrevista, que então é transcrita para o questionário, possibilitando a confecção de
relatórios acerca da funcionalidade das ferramentas, de modo a dar feedback
qualitativo sobre a experiência de demonstração.
O critério para a escolha de profissionais é: projetistas ou pesquisadores das áreas de
arquitetura ou engenharia civil, com conhecimento avançado comprovado por títulos
ou experiência profissional, acerca dos processos de atendimento à Norma de
Desempenho – no âmbito dos requisitos de desempenho acústico e/ou desempenho
101
lumínico, e que tenham contato com ferramentas computacionais de verificação ou
simulação de edificações.
Mais do que elucidar maneiras de aprimorar aspectos de uso dos artefatos
desenvolvidos e apresentar uma solução mais satisfatória, as avaliações propostas
foram estruturadas de modo que se torne um mecanismo gerador de feedback, e que
também possua meios de ser replicada e discutida em outras instâncias – projetos
reais de edificações ou futuros usuários avaliadores. Outra preocupação é não focar
apenas no desenvolvimento do artefato, mas sim na demonstração de que tal artefato
pode ser efetivamente utilizado para resolver problemas reais.
Em relação a outras maneiras de avaliar os artefatos, para Van Aken (2004), além da
avaliação metodológica, a efetividade do produto da pesquisa também pode ser
verificada em seu cenário proposto pela acumulação de implementações ou estudos
de caso. Tal abordagem, contudo, não poderá ser seguida no presente estudo devido
ao tempo para desenvolvimento do trabalho.
Acredita-se que, a partir da submissão das ferramentas ao mecanismo de testes
escolhido, avalia-se adequadamente aspectos potenciais de usabilidade,
versatilidade, utilidade e funcionalidade dos artefatos instanciações, possibilitando
discussões acerca de como estes atendem à solução dos problemas específicos
inicialmente propostos, bem como se possuem características que podem ser
generalizáveis em outros cenários.
102
6. PLUG-INS DESENVOLVIDOS
Este capítulo trata do dos resultados referentes ao desenvolvimento dos artefatos do
tipo instanciação, na forma de plug-ins para o software BIM escolhido. É dividida em
três momentos para cada temática específica: (1) primeiramente é apresentada uma
breve revisão bibliográfica para contextualização; (2) então, são apresentados os
projetos dos plug-ins, com fluxogramas de programação e ligação com as
informações de referência da Norma de Desempenho – tabelas, equações e requisitos;
(3) por fim, é apresentado o funcionamento de cada plug-in por meio da
demonstração de seu uso e como é feito o atendimento aos requisitos da Norma de
Desempenho.
6.1 Plug-in I: desempenho acústico de vedações verticais
Devido ao aumento nos critérios de qualidade de construções habitacionais, em
relação à amenidade acústica de ambientes e conforto dos habitantes, uma pressão
cada vez mais expressiva vem se estabelecendo nos processos de projeto de modo a
garantir o bem-estar dos usuários. Neste sentido, arquitetos e engenheiros necessitam
tomar decisões técnicas cruciais relacionadas a isolamento interno de ambientes para
proporcionar e garantir uma performance acústica adequada em seus projetos.
Uma série de aspectos de sistemas construtivos das edificações habitacionais tornam-
se indispensáveis nas decisões tecnológicas, aspectos que muitas vezes podem ser
mensurados, simulados e otimizados por meio de softwares específicos (ARJUNAN
et al., 2014; KIM; KIM, 2007).
Dentre as exigências da Norma de Desempenho está o desempenho acústico de
paredes de geminação entre ambientes de unidades autônomas e entre áreas
privativas ou comuns nas edificações multifamiliares, sendo necessários ensaios a
campo e em laboratório para verificação do desempenho em relação ao ruído aéreo
de sistemas construtivos.
Alternativas para facilitar e acelerar a predição de desempenho acústico de
ambientes internos e seu atendimento a normativas vem sendo estudados com o uso
de softwares de verificação e de simulação (TAKAHASHI, 2016). Neste contexto,
plug-ins e ferramentas para plataformas BIM emergiram como uma alternativa para
manipular e atingir melhorias de projeto de maneira rápida nas fases iniciais de
projeto (WU; CLAYTON, 2013).
Nestas situações, as esquadrias possuem um papel considerável no isolamento
acústico de paredes, servindo como um elemento de controle de ruído advindo do
103
exterior das edificações (KIM; KIM, 2007). Há uma importância na qualidade dos
produtos e da execução da esquadria para assegurar seu desempenho, bem como dos
materiais que compõe camadas da parede em que está instalada, um conjunto que
caracteriza sistemas construtivos e suas especificações dimensionais.
Devido ao fato de que a Norma de Desempenho não avalia elementos
individualmente, mas sim elementos que operam em um sistema (Figura 38), esta
seção apresenta uma proposta de plug-in para Revit que visa estimar o valor do
índice de redução sonora ponderado (RW) de sistemas de paredes de vedação
contando com suas esquadrias, considerando as diferentes possibilidades
dimensionais e de diferentes especificações relacionadas a portas e janelas.
Figura 38 - Índices de redução sonora individuais e do sistema
Fonte: Autor (2018).
Embora o plug-in proposto vise auxiliar no atendimento da Norma de Desempenho
Brasileira – Edificações Habitacionais (ABNT, 2013a), sua programação pode ser
customizada para se adaptar a outras normativas de abrangência internacional de
órgãos como BSI (British Standards Institution) e ISO (International Organization for
Standardization) (BSEN 12354-1, 2000; BSEN ISO 10140, 2010; BSEN ISO 717-1, 2006),
devido ao fato de que a metodologia envolvida é similar e baseada no isolamento de
ruído aéreo de paredes de vedação entre ambientes de uma edificação habitacional.
A ferramenta apresentada neste capítulo da pesquisa possui uma abordagem de
verificação do desempenho, possuindo a intenção de complementar e facilitar
estimativas relacionadas ao impacto de esquadrias como portas e janelas no
desempenho acústico de paredes de vedação, em uma diversidade de possíveis
104
sistemas construtivos em projetos, buscando a exploração de alternativas durante a
tomada de decisão.
Ao invés de realizar cálculos com tabelas e uso de dados oriundos de documentação
fragmentada, a proposta de desenvolvimento desta ferramenta busca a disrupção de
processos de projeto tradicionais voltados para performance, utilizando informações
inerentes dos modelos BIM para coletar informações atualizadas de propriedades
geométricas e de parâmetros relacionados à acústica de diferentes materiais
diretamente do modelo tridimensional – uma abordagem focada na modelagem e
não na documentação de projetos (EASTMAN et al., 2008). Embora Revit não possua
nativamente propriedades acústicas em suas funcionalidades, isto pode ser
adicionado por meio de programação.
Contudo, a ferramenta proposta não visa substituir softwares especializados de
simulação, com pesquisas mais aprofundadas almejadas em casos onde é necessária
uma maior precisão ou rigor técnico acerca da estimativa do índice de redução
sonora em sistemas construtivos (ARJUNAN et al., 2014; TAKAHASHI, 2016).
Através de rotinas de trabalho criadas no Dynamo, é proposta a manipulação de
dados extraidos de elementos BIM de um projeto para modificar o processo de
estimativa de desempenho acústico. Um conjunto de funcionalidades é apresentado,
visando calcular o índice de redução sonora (variável RW) de cada instância de
parede, porta e janela da modelagem, em determinada vista, planta ou fachada no
projeto da edificação.
6.1.1 Projeto do Plug-in I
Para manipular parâmetros de família de elementos do Revit e incluir propriedades
acústicas, é necessário criar um arquivo de Shared Parameters no Revit (Figura 39),
com dois principais parâmetros: RW – índice de redução sonora (parâmetro numérico,
comum a todas as paredes, janelas e portas), e RWsistema – índice de redução sonora
ponderado (parâmetro numérico, presente apenas em paredes).
Estes parâmetros têm a função de possibilitar a inserção de informações nos
elementos BIM para que a função de cálculo, aliada a informações geométricas como
área e dimensões de paredes e esquadrias, registrando os valores encontrados
diretamente nas paredes e esquadrias.
105
Figura 39 - Criação de Shared Parameters para acústica no Revit
Fonte: Autor (2018).
Então, de modo a possibilitar o uso da ferramenta para calcular e registrar
estimativas de desempenho são propostas as seguintes funcionalidades: (1) Calcular
RW – que define o valor do índice de redução sonora nas instâncias de parede e
esquadria conforme dados geométricos e de material do modelo; (2) Verificar
Desempenho – compara os valores obtidos no cálculo anterior com um valor de
desempenho desejado, preenchendo elementos na vista do Revit com escala de cores
de acordo com a conformidade com os requisitos normativos; (3) Reset – função que
reinicia os filtros de visualização do Revit na vista, removendo as cores geradas pela
verificação; e (4) Ajuda – que apresenta ao usuário informações suplementares na
forma de tabelas que apresentam critérios da norma.
Para a função principal do plug-in – (1) Calcular RW, ao executar a rotina, todos os
elementos da vista atual de projeto do Revit (planta baixa, corte, fachada ou 3D) são
selecionados e filtrados, apresentando todas as instâncias de parede, porta e janela na
vista. Então, um banco de dados com listas de tipos de famílias, valores de índice de
redução sonora e características de materiais é definido no algoritmo.
Tais listas de valores são pareadas com as instâncias de elementos do Revit
selecionados na etapa anterior e os valores de parâmetros são inseridos conforme o
tipo de família correspondente em cada instância na vista de projeto. Os parâmetros
do banco de dados seguem os valores apresentados na Norma NBR 15575-4 (ABNT,
106
2013d) e no Guia de Atendimento à Norma de Desempenho (CBIC, 2013), conforme
Tabela 1, mas podendo ser expandidos para abranger outros sistemas construtivos
customizados.
Tabela 1 - Valores indicativos do índice de redução sonora ponderado para alguns sistemas de paredes
Tipo de parede Largura do
bloco/tijolo (cm)
Revestimento Massa aprox.
(kg/m²)
Rw
(dBa)
Blocos vazados de
concreto
9 Argamassa 1,5 cm em
cada face
180 41
11,5 210 42
14 230 45
Blocos vazados de
cerâmica
9 Argamassa 1,5 cm em
cada face
120 38
11,5 150 40
14 180 42
Tijolos maciços de
barro cozido
11 Argamassa 2,0 cm em
cada face
260 45
15 320 47
11+11 * 450 52
Paredes maciças de
concreto armado
5 Sem revestimento 120 38
10 240 45
12 290 47
Drywall 2 chapas + lã de
vidro
Sem revestimento 22 41
4 chapas 44 45
4 chapas + lã de
vidro
46 49
* Parede dupla 11+11 cm, espaço interno de 4 cm preenchido com lã de rocha 70kg/m³
Fonte: Adaptado de Câmara Brasileira da Indústria da Construção (CBIC, 2013).
Alternativamente, é possível definir que o cálculo do RW de cada uma das paredes
utilize a fórmula de cálculo pela Lei das Massas (CBIC, 2013), possibilitando a
inserção de sistemas construtivos customizados conforme a massa do material
constituinte. Se isto ocorrer, a função busca o parâmetro de densidade dos materiais
componentes de cada camada da parede e sua respectiva espessura, retornando um
valor de RW conforme a fórmula:
𝑅𝑤 ≅ 12 + 5,3𝑀1
3 dB(A)
Onde: M = massa da parede em kg/m²
Na sequência, um novo filtro é definido para detectar propriedades de paredes do
tipo hospedeiro – que contenham esquadrias (janelas ou portas) anexadas, tais
paredes passam por uma equação para determinar o índice de redução sonora
ponderado, levando em consideração as áreas dos elementos hospedeiros presentes,
para ponderar o valor de RW dos sistemas construtivos (RW,Equiv) em cada ocorrência
na vista de projeto.
107
𝑅𝑤,𝐸𝑞𝑢𝑖𝑣 = 10 ∗ 𝑙𝑜𝑔𝑆𝑡𝑜𝑡𝑎𝑙
∑ 𝑆𝑖 ∗ 10−𝑅𝑤 𝑖
10𝑖=𝑛𝑖=0
Onde: RW,Equiv = Índice de redução sonora ponderado equivalente, em dB
Stotal = área total da parede (área da parte cega + área dos caixilhos) em m²
Si = área de cada componente individual da vedação (alvenaria, janela, porta etc) em m²
RWi = índice de redução sonora ponderado de cada componente (em dB).
Outras paredes na vista (paredes restantes, sem janelas ou portas anexadas) têm seu
valor de RWsistema definido como o mesmo de seu RW originalmente determinado –
na etapa de definição pela tabela ou configurado e calculado pela Lei das Massas.
Por fim, os valores RW e RWsistema calculados são registrados nos parâmetros dos
elementos, possibilitando aos projetistas avaliar o desempenho acústico calculado
das paredes de vedação diretamente no modelo BIM. Um resumo do ciclo destas
operações é apresentado no fluxograma da Figura 40.
Figura 40 - Fluxograma da função (1) Calcular Rw
Fonte: Autor (2018).
108
Na sequência, através da funcionalidade (2) Verificar desempenho, o usuário avalia
se quaisquer instâncias de parede em conjunto com portas e janelas atende aos
requerimentos mínimo, intermediário ou superior da NBR 15.575.
Para isto, é necessário que o usuário informe ao software qual é o nível de
desempenho desejado a ser analisado, por meio da inserção de uma margem de
valores (valor médio, +5 dB, -5 dB) diretamente na interface do software. Então,
conforme a tipologia de ambientes da edificação, elementos de parede da vista atual
são coletados e, considerando a situação de paredes entre ambientes ou parede de
fachada, podem ser registrados valores em conformidade com as disposições da
Tabela 2 e Tabela 3.
Tabela 2 - Diferença padronizada de nível ponderada entre ambientes
Elemento Dn,Tw
(dB)
Nível de
Desempenho
Parede entre unidades habitacionais autônomas (parede de geminação),
nas situações onde não haja ambiente dormitório
40 a 44 Mínimo
45 a 49 Intermediário
>= 50 Superior
Parede entre unidades habitacionais autônomas (parede de geminação),
no caso de pelo menos um dos ambientes ser dormitório
45 a 49 Mínimo
50 a 55 Intermediário
>= 55 Superior
Parede cega de dormitórios entre uma unidade habitacional e áreas
comuns de trânsito eventual, tais como corredores e escadaria nos
pavimentos
40 a 44 Mínimo
45 a 49 Intermediário
>= 50 Superior
Parede cega de salas e cozinhas entre uma unidade habitacional e áreas
comuns de trânsito eventual, tais como corredores e escadaria dos
pavimentos
30 a 34 Mínimo
35 a 39 Intermediário
>= 40 Superior
Parede cega entre uma unidade habitacional e áreas comuns de
permanência de pessoas, atividades de lazer e atividades esportivas, tais
como home theater, salas de ginástica, salão de festas, salão de jogos,
banheiros e vestiários coletivos, cozinhas e lavanderias coletivas
45 a 49 Mínimo
50 a 54 Intermediário
>= 55 Superior
Conjunto de paredes e portas de unidades distintas separadas pelo hall
(valor entre as unidades)
40 a 44 Mínimo
45 a 49 Intermediário
>= 50 Superior
Fonte: Adaptado de NBR 15.575-4 (ABNT, 2013b) e Câmara Brasileira da Indústria da Construção
(CBIC, 2013).
109
Tabela 3 - Índice de redução sonora ponderado para fachadas
Classe de
Ruído Localização da habitação
Rw*
(dB)
Nível de
desempenho
I Habitação localizada distante de fontes de ruído intenso
de quaisquer naturezas
>=25 Mínimo
>=30 Intermediário
>=35 Superior
II Habitação localizada em áreas sujeitas a situações de
ruído não enquadráveis nas classes I e III
>=30 Mínimo
>=35 Intermediário
>=40 Superior
III
Habitação sujeita a ruído intenso de meios de transporte e
de outras naturezas, desde que esteja de acordo com a
legislação
>=35 Mínimo
>=40 Intermediário
>=45 Superior
(*) valores aproximados / ordem de grandeza para potencial atendimento na situação real de campo
Fonte: Adaptado de NBR 15.575-4 (ABNT, 2013b) e Câmara Brasileira da Indústria da Construção
(CBIC, 2013).
Por meio de uma escala de cores aplicada com filtros no Revit, a rotina então
preenche os elementos de parede na vista atual de projeto, conforme o resultado da
comparação entre o valor calculado e o valor desejado de desempenho. Isto
possibilita aos projetistas verificar se o desempenho acústico dos sistemas de parede
e esquadria está atendendo os níveis de desempenho determinados. Um fluxograma
para esta funcionalidade é apresentado na Figura 41.
Figura 41 - Fluxograma da função (2) Verificar Desempenho
Fonte: Autor (2018).
110
De modo que os processos descritos sejam reversíveis e facilmente refeitos, a função
(3) Reset (Figura 42), realiza a reinicialização dos filtros da vista atual, removendo
quaisquer escalas de cores inputada nos elementos de parede. Para isto, basta que os
filtros criados pela função anterior sejam apagados. Esta função possibilita que o
usuário crie situações de desempenho desejado diferentes, para avaliar se certas
composições de paredes atendem os critérios em cenários variados, possibilitando
novos cálculos e verificações desde o início e também facilitando processos de
geração de documentação.
Figura 42 - Fluxograma da função (3) Reset para o plug-in de desempenho acústico
Fonte: Autor (2018).
Por fim, para suplementar o processo de escolha do desempenho desejado e para
consultar dados referenciais da normativa, é proposta a função (4) Ajuda (Figura 43).
Por meio de uma interface, o usuário pode ter acesso a informações das Tabela 2 e
Tabela 3, apresentando dados referentes aos valores necessários para os níveis
Mínimo, Intermediário ou Superior diretamente pelo Revit, por meio de janelas pop-
up a serem mostradas conforme escolha do usuário.
111
Figura 43 - Fluxograma da função (4) Ajuda para o plug-in de desempenho acústico
Fonte: Autor (2018).
6.1.2 Funcionamento e desenvolvimento do Plug-in I
A programação das funções do plug-in está disponível na íntegra no Apêndice C.
Os principais resultados da ferramenta desenvolvida podem ser observados por
meio de aplicação prática do algoritmo durante seu uso no Revit, esta seção
apresenta as funcionalidades e lógica de programação envolvida. Os parâmetros de
performance acústica (RW e RWsistema) são inseridos em paredes, portas e janelas no
Revit, por meio da customização de Shared Parameters, acompanhando os critérios do
projeto.
O algoritmo da função (1) Calcular Rw preenche tais parâmetros com informações de
acordo com o banco de dados de índices de redução sonora cadastrado de sistemas
construtivos padrão, considerando as diferentes composições de parede e esquadrias
anexadas no modelo BIM, e definindo o valor de RW de portas, janelas e paredes na
vista atual conforme seus respectivos sistemas construtivos. Esta informação aparece
diretamente nas propriedades dos elementos (Figura 44).
112
Figura 44 – Parâmetros registrados nas propriedades dos elementos
Fonte: Autor (2018).
Para demonstração, algumas configurações de parede e esquadrias foram criadas
como famílias do Revit (Figura 45). As famílias cadastradas seguem as disposições da
Tabela 1 - Valores indicativos do índice de redução sonora ponderado para alguns
sistemas de paredes, a qual foi apresentada no item anterior (6.1.1) deste trabalho.
Para melhor visualização, RW e RWsistema de famílias são apresentados como objetos
de Anotação do Revit, remetendo aos valores encontrados em cada conjunto parede e
esquadrias.
Figura 45 – Vista de planta baixa com famílias de parede e esquadrias cadastradas
Fonte: Autor (2018).
113
Conforme o projeto da ferramenta, a partir dos parâmetros de área de cada instância
de parede, janela e porta na vista atual, o algoritmo detecta elementos de parede do
tipo hospedeiro (Host Walls) e suas respectivas janelas e portas (Hosted Elements),
calculando o índice de redução sonora, identificado como RWsistema.
Nesta etapa, um código em Python (Figura 46) foi implementado para facilitar a
relação entre o banco de dados de famílias cadastrado e os respectivos valores de Rw,
considerando as múltiplas possibilidades existentes em um modelo, de modo a
reduzir a quantidade de funções do Dynamo a serem criadas para executar
operações de verificação lógica entre listas e possivelmente reduzir tempos de
processamento.
Figura 46 - Código em Python para organização de listas e instâncias de paredes
Fonte: Autor (2018).
Durante o desenvolvimento da ferramenta, um problema relevante foi solucionado
por meio de programação: por vezes o parâmetro interno de área de elementos de
janelas e portas do Revit erroneamente retorna a soma de todas as áreas de superfície
em sua composição. Utilizando funções do Dynamo como ‘bounding box’ e
‘intersecção com o plano Z’ conforme a orientação de cada parede, foi possível
registrar a área real de janelas e portas, corrigindo o parâmetro de área necessário no
cálculo de RW, como demonstrado na Figura 47.
114
Figura 47 - Ambiente Dynamo e definição de intersecções entre planos e geometria de janelas
Fonte: Autor (2018).
Esta medida também foi necessária para cobrir uma maior quantidade de elementos
de famílias a serem importadas no modelo BIM – devido ao fato de que muitas
famílias são feitas por usuários e podem não possuir parâmetros específicos bem
denominados como altura e largura (podendo inclusive ser referenciados em outras
línguas e na escala imperial, complicando ainda mais tal situação). Isto
possivelmente tornará o plug-in mais adaptável a diferentes particularidades de
famílias de portas e janelas a serem importadas e calculadas no modelo.
Em relação ao preenchimento dos elementos com escala de cores, o potencial de uso
do plug-in está na possibilidade de auxiliar profissionais da AEC na otimização da
performance acústica de seus projetos ao facilitar a compreensão do impacto de
diferentes escolhas de materiais de paredes e esquadrias durante suas decisões. O
plug-in, portanto, é apresentado como uma alternativa aos métodos tradicionais de
análise de performance, complementando outros softwares.
Ao executar a função (2) Verificar desempenho, uma janela é aberta (Figura 48) para
que o usuário defina o valor médio de Rw desejado. Desta forma, o algoritmo
interpreta este input e cria uma série de filtros de vista na interface do Revit,
configurados com condicionantes em uma margem de -5 dB e +5 dB do valor
estipulado para alterar a representação de cores de elementos de parede (Figura 49).
Os filtros podem ser customizados pelo usuário conforme sua cor e linhas (Figura
50).
115
Figura 48 - Janela para definição do valor médio de Rw
Fonte: Autor (2018).
Figura 49 - Configurações de condicionantes para os filtros criados (desempenho acústico)
Fonte: Autor (2018).
Figura 50 - Configurações de visibilidade para os filtros criados (desempenho acústico)
Fonte: Autor (2018).
116
A Figura 51 demonstra algumas possibilidades de utilizar esta ferramenta,
apresentando um resultado de execução das funções (1) Calcular Rw e (2) Verificar
desempenho, em uma vista de planta baixa, com diferentes tipos de sistemas
construtivos de paredes (alvenaria, concreto e drywall), com múltiplas dimensões,
bem como famílias de janelas e portas em quantidades variáveis por parede – em
resumo, um conjunto de possíveis situações que espelham a complexidade de
projetos reais, onde a diversificação de sistemas construtivos impacta o desempenho
acústico e possibilita a tomada de decisões de projeto otimizada para as soluções
tecnológicas a serem empregadas.
Figura 51 - Resultados do cálculo e verificação de modelos
Fonte: Autor (2018).
117
Em relação à função (4) Ajuda, o usuário é apresentado à janela da Figura 52,
podendo escolher uma das opções de dados referenciais. Ao confirmar a opção, um
arquivo de imagem contendo a tabela correspondente é apresentado ao usuário
diretamente pelo Revit, conforme as Tabela 2 e Tabela 3, apresentadas no item
anterior (6.1.1).
Figura 52 - Janela de opções da função (4) Ajuda
Fonte: Autor (2018).
Quanto à maneira como as funcionalidades estão apresentadas no Revit: a
organização é feita por meio de botões incluídos pela programação do Dyno
Browser, apresentadas no Revit por uma aba específica (jDesempenho) em sua
interface, representando as rotinas configuradas no Dynamo (Figura 53). Toda vez
que um botão for clicado pelo usuário, além da execução da rotina sem a necessidade
de abrir a extensão Dynamo, a definição de critérios antes que a função a seja
executada, quando aplicável, se torna possível por meio das janelas pop-up criadas
com o o uso do pacote do Dynamo Data-Shapes.
Figura 53 - Aba de funções de desempenho e ícones para desempenho acústico
Fonte: Autor (2018).
118
Alternativamente, o usuário também pode utilizar a lista de rotinas do Dyno Browser
(Figura 54), disponível na interface do Revit, com o mesmo efeito, podendo,
adicionalmente, ter informações acerca do tempo de execução das rotinas, possíveis
erros durante os processos, acompanhamento dos resultados parciais de algumas
etapas da programação e a pré-customização ou modificação de algumas variáveis
sem abrir o Dynamo.
Figura 54 - Navegador do Dyno Browser e as rotinas configuradas
Fonte: Autor (2018).
Em relação ao modo como os ícones foram criados na aba do Revit, inicialmente foi
editado o arquivo de texto “buttons.txt”, presente na instalação e acessível nas
configurações da ferramenta Dyno Browser (PRORUBIM, 2017), com um código
curto que representa a ordem e separação das funções dos plug-ins de desempenho
acústico e lumínico (Figura 55).
Figura 55 - Arquivo de texto do Dyno Browser e sua configuração
Fonte: Autor (2018).
Então, na pasta onde estão localizadas as rotinas do Dynamo (Figura 56), estas foram
renomeadas conforme a lista do arquivo de texto, para que este interprete estas
informações de forma ordenada e crie os respectivos botões na aba “jDesempenho”
no Revit. Em relação aos ícones, basta incluir arquivos de imagem no formato .PNG,
119
utilizando o mesmo nome da rotina que este representa, para que apareça
corretamente na interface de abas.
Figura 56 – Pasta contendo rotinas do plug-in para acústica e suas respectivas imagens de ícone
Fonte: Autor (2018).
6.2 Plug-in II: desempenho lumínico de ambientes internos
O desempenho lumínico das edificações habitacionais é de grande importância para
o desenvolvimento de projetos energéticamente eficientes e ambientação confortável
ao usuário. A iluminação natural deve ser aproveitada ao máximo como um recurso
disponível durante o dia, sendo complementada pela iluminação artificial à noite.
Critérios de desempenho necessitam ser integrados no projeto arquitetônico para dar
ênfase na performance da edificação nas etapas iniciais, de modo a explorar os
potenciais de melhorar conforto, produtivididade, qualidade de vida e até mesmo a
saúde dos usuários (DAVOODI, 2016).
Ferramentas computacionais relacionadas ao desempenho lumínico utilizando novas
tecnologias vem sendo abordadas na literatura recente, com análises em softwares
como EnergyPlus (ENERGYPLUS, 2017), Daysim (DAYSIM, 2017), Ecotect
(AUTODESK, 2016), Radiance (RADIANCE, 2017) e outros. Tais ferramentas visam
oferecer dados relevantes aos projetistas para que possam fazer decisões conscientes
acerca do conforto lumínico e eficiência energética de seus projetos (DAVOODI,
2016), viabilizando a análise de diversos cenários de posicionamento, aberturas e
orientação solar, apresentando alternativas de possíveis soluções com agilidade e
redução de erros humanos (FELIPPE et al., 2015).
Por outra ótica, a NBR 15.575-1: Edificações Habitacionais – Desempenho (ABNT,
2013a) reforça esta necessidade de incorporar propriedades de eficiência e conforto
120
nas residências. Quanto ao desempenho lumínico, a Norma de Desempenho
estabelece níveis de iluminância e fator de luz diurna para edificações habitacionais
que devem ser atendidos por meio dos projetos contando unicamente com a
iluminação natural, considerando o tipo de atividade a ser exercida na habitação.
Tais aspectos envolvem intensamente propriedades de sistemas construtivos,
esquadrias e dimensionamento de ambientes, um conjunto de informações que traz
diversidade de soluções tecnológicas no ambiente de projeto. Em suas disposições é
destacado que a medição do desempenho lumínico de ambientes deve seguir a
metodologia de um algoritmo para verificação da iluminância geral para os níveis de
desempenho mínimo, intermediário ou superior, variáveis conforme o ambiente
analisado. Tal algoritmo a ser empregado nas análises de iluminâncias internas é
disposto na NBR 15.215: Iluminação natural – Parte 3 : Procedimento de cálculo para
a determinação da iluminação natural em ambientes internos (ABNT, 2004).
A metodologia do cálculo de iluminâncias internas apresentada na NBR 15.215-3 é
também abordada no trabalho de Souza (1997), que realizou medições, propôs
processos e simulações em modelos reduzidos, de modo a estimar os valores de
desempenho lumínico no interior de habitações. Os experimentos do estudo se
destacaram, com estimativas de valores próximas do real, sendo replicadas até o dia
de hoje com sua facilidade de aplicação e possibilidade de uso em diversos projetos
(SOUZA, 1997).
Contudo, a metodologia descrita envolve o uso de máscaras, ábacos e desenhos
geométricos planificados, que complicam a adequação do procedimento às novas
tecnologias, tridimensionais e paramétricas. Com isso, é necessário buscar
alternativas para simular e estimar os níveis de iluminância nos ambientes internos,
abordando novas ferramentas, de modo a integrar este processo a metodologias e
processos inovadores como o BIM. Para isso, são também propostos estudos
comparativos de modo a aferir a precisão e analisar a possibilidade de uso de novas
ferramentas que atinjam resultados semelhantes.
No contexto apresentado, o objetivo desta seção é propor uma programação de plug-
in para a plataforma BIM Autodesk Revit, para auxiliar projetistas no cálculo de
desempenho lumínico natural de ambientes, visando a melhoria e adequação de seus
projetos de acordo com os requisitos da NBR 15.575, verificando a possibilidade de
uso de novas tecnologias para calcular iluminâncias internas e de representa-las no
projeto de arquitetura.
121
6.2.1 Projeto do Plug-in II
Assim como feito no plug-in para desempenho acústico, é necessário criar alguns
parâmetros no Revit por meio da opção Shared Parameters (Figura 57). Os dois
parâmetros são de caráter numérico: Lux – iluminância nas superfícies; e FLD – Fator
de Luz Diurna (%).
Figura 57 - Criação de Shared Parameters para iluminação no Revit
Fonte: Autor (2018).
Dentre as funcionalidades propostas estão: (1) Gerar Grid – que cria uma malha no
interior de ambientes para possibilitar análises; (2) Análise de Iluminâncias Internas –
para determinação da iluminância de ambientes internos, por meio de uma escala de
cores, conforme geometria de seu espaço e aberturas; (3) Análise de Fator de Luz
Diurna – para determinação do FLD de ambientes internos, por meio de uma escala
de cores; (3) Reset - função que apaga os resultados anteriores, removendo as malhas
geradas pela análise; e (4) Ajuda – função suplementar que apresenta algumas
tabelas de referência ao usuário.
Durante a função inicial do plug-in – (1) Gerar Grid, o usuário deve inserir algumas
informações: que ambientes irão ser analisados – por meio da seleção de elementos
do tipo “Room” no Revit; informar dados do período a ser analisado (dia, mês e
horário); bem como a importar um arquivo de informações climáticas do software
EnergyPlus (extensão .epw) – contendo dados do local onde a edificação está
localizada, entre diversos outros parâmetros (ENERGYPLUS, 2017).
122
Com estas informações, é possível criar um ambiente de simulação conforme os
critérios descritos pela Norma de Desempenho em seu item 13.2.2 – Método de
Avaliação (ABNT, 2013a), que exige a contemplação de algumas condições de
simulação. A Tabela 4 apresenta como tais informações são capturadas na
programação pelo Dynamo.
Tabela 4 - Captura de informações necessárias no plug-in de desempenho lumínico
Condições Captura no Dynamo
Períodos da manhã (9h30min) e tarde
(15h30min)
Input do usuário na
interface
Dias 23 de abril e 23 de outubro Input do usuário na
interface
Latitude e longitude da obra Importação de arquivo
.epw
Nebulosidade 50% Parâmetro existente nos
arquivos .epw
Simulações para o centro dos
ambientes
Centro do elemento “room”
no Revit
Altura de análise de 0,75m acima do
nível do piso
Offset do elemento de piso
no Revit
Fonte: condições adaptadas de item 13.2.2 da NBR 15.575-1 (ABNT, 2013a).
Ao confirmar a opção, os elementos de ambientes – Rooms – da vista atual de projeto
são coletados. Informações relativas às paredes que compõe cada ambiente, bem
como as aberturas (janelas) de tais paredes são adicionadas na programação. Por
meio de algumas funções do Honeybee, os ambientes previamente selecionados são
subdivididos em uma malha ortogonal com linhas espaçadas a cada 0,50 m no eixo
geométrico, criado a uma distância 0,75 m do piso dos mesmos.
Na sequência, conforme a selação do horário, dia e mês determinado, o modelo do
céu e a trajetória do sol, na determinada localidade, é traçado no ambiente do Revit.
A partir de uma das funções do Ladybug e Honeybee, que realiza análise de
iluminância ou FLD externalizada pelo software Radiance (RADIANCE, 2017), o
conjunto de geometrias de ambientes, paredes e aberturas é processado por meio de
Ray-tracing, tendo como resultado uma lista de valores de incidência de raios solares
em superfícies, que então é convertida para a unidade de iluminância lux ou fator de
luz diurna (%).
Tal lista de valores é então pareada às superfícies criadas pela malha na etapa
anterior, criando uma série de elementos genéricos no Revit, superfícies que
compõem uma malha dotada de informações de iluminância ou %FLD, conforme o
tipo de análise selecionada pelo usuário. O resumo do processo descrito é
apresentado na Figura 58.
123
Figura 58 - Fluxograma da função (1) Gerar Grid
Fonte: Autor (2018).
Com os elementos genéricos criados no ambiente do Revit e seus parâmetros
preenchidos, o usuário pode utilizar as funções (2) Análise Lux e (3) Análise FLD
para realizar a verificação do desempenho. Através destas funções, são criados filtros
por uma escala de cores de vista que atua apenas nos elementos genéricos criados na
malha. Os filtros são então aplicados em cada uma das superfícies analisadas,
preenchendo a malha dos ambientes conforme a iluminância (lux) ou o fator de luz
diurna (FLD) em cada segmento.
Isto permite a verificação com os requisitos da Norma de Desempenho, que
estabelece níveis de iluminamento e de fator de luz diurna para atendimento
Mínimo, Intermediário ou Superior conforme o tipo de ambiente analisado, conforme
Tabela 5 e Tabela 6.
124
Tabela 5 - Níveis de iluminância para iluminação natural
Ambientes/Nível de Desempenho
Iluminamento geral para os níveis de
desempenho (lux)
Mínimo* Intermediário Superior
Sala de Estar, Dormitório, Copa/cozinha, Área de Serviço >=60 >=90 >=120
Banheiro, Corredor ou escada interna à unidade,
Corredor de uso comum (prédios), Escadaria de uso
comum (prédios), Garagens e estacionamentos
Não
requerido >=30 >=45
*Valores mínimos obrigatórios, conforme Critério 13.2.1 da NBR 15.575-1 (ABNT, 2013a)
Nota 1 – Para os edifícios multipiso são permitidos para as dependências situadas no pavimento
térreo ou em pavimentos abaixo da cota da rua níveis de iluminância ligeiramente inferiores aos
valores especificados na tabela acima (diferênça máxima de 20% em qualquer dependência).
Nota 2 – Os critérios desta tabela não se aplicam às áreas confinadas ou que não tenham iluminação
natural.
Nota 3 – Deve-se verificar e atender as condições mínimas requeridas pela legislação local.
Fonte: Adaptado de NBR 15.575-4 (ABNT, 2013b) e Câmara Brasileira da Indústria da Construção
(CBIC, 2013).
Tabela 6 - Fator de luz diurna para os diferentes ambientes da habitação
Dependência
FLD (%) para os níveis de
desempenho
Mínimo* Intermediário Superior
Sala de estar, Dormitório, Copa/cozinha, Área de serviço > 0,50% >= 0,65% >= 0,75%
Banheiro, Corredor ou escada interna à unidade, Corredor
de uso comum (prédios), Escadaria de uso comum
(prédios), Garagens e estacionamentos
Não
requerido >= 0,25% >= 0,35%
*Valores mínimos obrigatórios, conforme Critério 13.2.3 da NBR 15.575-1 (ABNT, 2013a)
Nota 1 – Para os edifícios multipiso, são permitidos para as dependências situadas no pavimento
térreo ou em pavimentos abaixo da cota da rua níveis de iluminância ligeiramente inferiores aos
valores especificados na tabela acima (diferênça máxima de 20% em qualquer dependência).
Nota 2 – Os critérios desta tabela não se aplicam às áreas confinadas ou que não tenham iluminação
natural.
Fonte: Adaptado de NBR 15.575-4 (ABNT, 2013b) e Câmara Brasileira da Indústria da Construção
(CBIC, 2013).
Além disso, o procedimento permite que os projetistas visualizem de forma gráfica o
desempenho lumínico em cada ambiente, tornando flexível o processo de
posicionamento de aberturas, escolha e dimensionamento de materiais e orientação
solar da edificação, através da mudança destas variáveis diretamente na modelagem
de arquitetura pelo Revit e pela geração e análise de malhas. Um fluxograma geral de
funcionamento de (2) Análise Lux e (3) Análise FLD é apresentado na Figura 59.
125
Figura 59 - Fluxograma das funções (2) Análise Lux e (3) Análise FLD
Fonte: Autor (2018).
Assim como no plug-in de desempenho acústico, o uso dos filtros pode ser feito
livremente pelo usuário para compor documentação de comprovação de
desempenho pelo Revit, utilizando os ambientes analisados, por meio da construção
de cenários variados utilizando diferentes orientações, aberturas, datas, horários ou
composições de ambientes. Para facilitar este processo de geração de diversas
análises, também é necessário o comando (4) Reset, que possibilita, além da
reinicialização dos filtros da vista atual, a exclusão dos elementos genéricos de malha
criados por análises anteriores (Figura 60).
126
Figura 60 - Fluxograma da função (4) Reset para o plug-in de desempenho lumínico
Fonte: Autor (2018).
Por fim, também é proposta a função (5) Ajuda, que, similarmente ao realizado no
plug-in de desempenho acústico, apresenta o conteúdo das Tabela 5 e Tabela 6 ao
usuário, por meio de pop-ups (Figura 61).
Figura 61 - Fluxograma da função (5) Ajuda para o plug-in de desempenho lumínico
Fonte: Autor (2018).
127
6.2.2 Funcionamento e desenvolvimento do Plug-in II
A programação das funções do plug-in está disponível na íntegra no Apêndice C.
A ferramenta proposta, assim como o plug-in de desempenho acústico, é
programada através da extensão Dynamo e funciona por meio de botões na interface
do Revit, através do Dyno Browser. Dentre os diversos pacotes de funções utilizados
no ambiente Dynamo, destacam-se Ladybug e Honeybee (LADYBUG, 2018), pacotes
originários do plug-in Grasshopper para Rhino 3D, mas que recentemente estão
sendo adaptados para a plataforma BIM. Ladybug e Honeybee oferecem soluções
voltadas para análises energéticas, que possibilitam o uso de funções para a eficiência
e design paramétrico orientado ao desempenho (ROUDSARI et al., 2013). Assim, o
plug-in programado é uma adaptação de um conjunto de ferramentas já existentes,
customizadas para serem inseridas no contexto da Norma de Desempenho Brasileira.
Assim como para o plug-in acústico, os resultados podem ser demonstrados por
meio do uso da ferramenta. Para tal, e para apresentar como o processo de
atendimento ao desempenho pode ser feito, foram criados alguns ambientes no Revit
para análise.
Inicialmente, ao executar a função (1) Gerar Grid, o usuário é apresentado aos inputs
descritos no projeto do plug-in. Uma janela pop-up é criada (Figura 62) onde é
necessária a busca por um arquivo .epw contendo a localização da edificação, bem
como dados de dia, mês, horário e tipo de análise (Iluminância ou Fator de Luz
Diurna). Os ambientes a serem analisados também podem ser escolhidos e
confirmados no Revit por meio de um botão que permite apenas a seleção de
elementos BIM do tipo “Room”. Esta série de parâmetros então é gravada no
algoritmo, e em conjunto com informações de paredes e de aberturas, possibilita a
geração do grid, criando uma série de elementos genéricos numerados dentro de
cada ambiente analisado (Figura 63). Os elementos genéricos são superfícies
espaçadas a cada 0,5m, posicionadas a uma altura de 0,75m do piso.
Ao confirmar a escolha dos parâmetros, paralelamente também é possível observar o
traçado da trajetória do sol no ambiente de modelagem conforme o que foi
configurado (Figura 64). Este traçado é independente e não utiliza de quaisquer
configurações prévias no ambiente do Revit (estudos solares ou caminho do sol), pois
está vinculado à programação e às informações do arquivo de informações climáticas
selecionado.
128
Figura 62 - Janela de opções de input para a função (1) Gerar Grid
Fonte: Autor (2018).
Figura 63 - Malha de elementos genéricos dentro de um ambiente
Fonte: Autor (2018).
129
Figura 64 - Traçado das trajetórias do sol, vista superior e tridimensional
Fonte: Autor (2018).
Com o grid definido, o usuário pode executar as funções (2) Análise Lux e (3) Análise
FLD, para preencher os elementos genéricos com uma escala de cores. A partir da
análise do grid, são realizadas operações internamente na programação por meio de
componentes do Dynamo que externalizam os cálculos por Ray-Tracing para o
software Radiance, que é aberto em uma janela de prompt de comandos, capturando
as informações geométricas e climáticas e gerando uma lista de valores resultantes da
interação escolhida – iluminância ou FLD.
Os resultados desta lista de valores são então pareados com cada geometria gerada
no Grid, assim, cada respectivo elemento genérico possui um valor definido no
parâmetro Lux ou FLD. O que permite que as funções (2) e (3) do plug-in apenas
criem filtros de vista para preencher os elementos com cores (Figura 65).
Figura 65 - Preenchimento da malha com os resultados para iluminância
Fonte: Autor (2018).
130
Assim como no plug-in para desempenho acústico, os filtros de vista são criados
especificamente para uma categoria de elementos, neste caso, para o tipo Generic
Models (Figura 66). Uma série de filtros é criada a partir de intervalos, utilizando
condicionantes para detectar os valores dos parâmetros. O usuário também pode
editar as cores utilizadas e seus intervalos no Revit se assim desejar por meio da
edição das configurações de visibilidade (Figura 67).
Figura 66 - Configurações de condicionantes para os filtros criados (desempenho lumínico)
Fonte: Autor (2018).
Figura 67 - Configurações de visibilidade para os filtros criados (desempenho lumínico)
Fonte: Autor (2018).
131
Com as funções de geração de grids e preenchimento com escala de cores é possível
verificar se certas composições de ambientes atendem ao desempenho estipulado na
normativa por meio do uso de, por exemplo, funções de anotação do Revit, que
resgatam o valor de um parâmetro e possibilitam ao usuário explicitar esta
informação diretamente no ambiente do projeto.
Para demonstrar o funcionamento do plug-in em situações diversas, foram criados
alguns ambientes no Revit (Figura 68), com dimensões de área 24m² (6m x 4m), pé
direito de 3m, fachada de aberturas apontada para o norte, e com o arquivo climático
da cidade de Passo Fundo/RS. Foram adicionadas algumas configurações de
posicionamento de janelas, para avaliar a diferença que este parâmetro tem na
estimativa do desempenho lumínico.
Figura 68 - Modelagem 3D de ambientes com diferentes configurações de aberturas
Fonte: Autor (2018).
Devido ao fato de que a Norma de Desempenho estipula que o período de análise
deve ser feito nos dias 23 de abril e 23 de outubro, nas horas 9:30 e 15:30, foi
calculada a iluminância por em cada ponto e a geração de grids nas 4 situações, com
os respectivos componentes genéricos preenchidos por uma escala de cores
correspondente ao valor encontrado (Figura 69). O valor apresentado abaixo de cada
ambiente corresponde à iluminância no centro deste, em diferentes configurações de
aberturas.
132
Figura 69 - Resultados da análise para os ambientes em vista de planta baixa
Fonte: Autor (2018).
Esta abordagem permite ao projetista flexibilizar seus processos enquanto
compreende o comportamento do desempenho lumínico de seus projetos, pois
permite que tenha um feedback visual acerca da efetividade de suas soluções
diretamente no Revit, ao mesmo tempo em que projeta e explora alternativas de
aberturas e dimensionamento de ambientes no software BIM. Além de possibilitar a
verificação da iluminância de diferentes configurações de cada ambiente, em cada
situação exigida pela norma, possibilita suplementar a geração de relatórios ou
documentação de desempenho, que demonstrem que os ambientes analisados estão
atendendo os requisitos.
Para demonstrar a flexibilidade da customização dos dados pela programação, foi
modelado um projeto simples de uma edificação (Figura 70). É possível realizar as
análises em mais de um ambiente simultaneamente, independente da forma ou
dimensões que o compõe, e em horários além dos especificados na Norma de
Desempenho (Figura 71). Além disso, através da edição das condicionantes dos
filtros na interface do Revit, é possível customizar as análises para, por exemplo,
133
representar cores nos intervalos de níveis de desempenho ao invés de iluminância
(Figura 72).
Figura 70 - Projeto exemplo para análise de desempenho lumínico
Fonte: Autor (2018).
Figura 71 - Resultados da análise de iluminância no projeto exemplo em diferentes horários
Fonte: Autor (2018).
134
Figura 72 - Customização das escalas de cor para uma escala de desempenho no projeto exemplo
Fonte: Autor (2018).
Em relação às funcionalidades restantes, assim como o plug-in de desempenho
acústico, a ferramenta conta com botões de (4) Reset e (5) Ajuda. O reset possui a
opção adicional de deletar os elementos do grid além dos filtros aplicados na vista,
permitindo a geração de novas malhas de análise para outros cenários.
A função (5) Ajuda conta com tabelas de referência para atendimento ao
desempenho lumínico no interior de ambientes considerando a iluminância ou o
fator de luz diurna, conforme as Tabela 5 e Tabela 6, apresentadas no item 6.2.1. Ao
ser executada, esta função apresenta uma pop-up ao usuário para que escolha qual
tabela será consultada (Figura 73).
135
Figura 73 - Janela de opções da função (5) Ajuda
Fonte: Autor (2018).
Quanto à apresentação na interface do Revit, a configuração no Dyno Browser ocorre
da mesma maneira que no plug-in de desempenho acústico. É configurando o
arquivo “buttons.txt”, definindo nomes e respectivos ícones para que as rotinas
organizadas na pasta apareçam corretamente na aba de desempenho do Revit e
possam ser utilizadas (Figura 74).
Figura 74 - Aba de funções de desempenho e ícones para desempenho lumínico
Fonte: Autor (2018).
136
7. AVALIAÇÃO DOS PLUG-INS
Este capítulo consiste na aplicação dos métodos de avaliação descritos na
metodologia, para isto, é dividido em três momentos: (1) primeiramente, são
detalhados os mecanismos de avaliação por meio dos questionários desenvolvidos
para cada plug-in; (2) então, são apresentadas as partes envolvidas no processo, com
a descrição da experiência por meio das abordagens Black Box com os convidados; (3)
por fim, com discussão acerca do feedback obtido, são explicitados os principais
resultados do ciclo de avaliação dos dois artefatos do tipo instanciação
desenvolvidos, os ajustes necessários e a importância desta etapa no processo
metodológico.
7.1 Questionário para avaliação
Conforme discutido no item 5.3.2 do trabalho, foi utilizado como mecanismo de
avaliação um questionário direcionado a profissionais, conforme os critérios
estabelecidos no método.
No intuito de possibilitar o alinhamento com a abordagem Cause-Effect Graph,
buscou-se organizar as questões conforme cada funcionalidade dos plug-ins, para
que durante experiências de avaliação com profissionais, possam ser identificadas as
características e particularidades de cada função programada e assim, evidenciar se
os artefatos desenvolvidos cumprem as funções planejadas no cenário.
O questionário conta principalmente com perguntas narrativas de resposta livre,
voltadas para o direcionamento de discussão e para levantar possíveis problemas
não descobertos durante a etapa de desenvolvimento. Em cada funcionalidade
desenvolvida, estas perguntas possuem uma base estruturante em comum,
relacionada ao funcionamento básico, como: “A função operou da maneira
pretendida?” e “Alguma opção adicional deveria ser incluída?”, bem como
perguntas mais específicas às funcionalidades, relativas à inserção de inputs, maneira
como as informações estão apresentadas, entre outras.
A lista de perguntas narrativas e as funcionalidades às quais se referem estão
elencadas na Tabela 7 para o plug-in de desempenho acústico e na Tabela 8 para o
plug-in de desempenho lumínico.
137
Tabela 7 - Questionamentos para avaliação do plug-in de desempenho acústico
Seção Questionamentos
(1) Calcular
Rw
1. A função operou da maneira pretendida? Se não, por quê?
2. O input de informações é suficiente? Algum parâmetro necessário para o cálculo
não foi considerado?
3. Quanto a inserção e configuração de novos materiais e sistemas construtivos, como
isto poderia ser melhorado?
4. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
(2) Verificar
Desempenho
1. A função operou da maneira pretendida? Se não, por quê?
2. A maneira como a escala de cores é aplicada (variações de um valor definido) é
adequada? Como poderia ser melhorada?
3. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
4. Avalie o potencial para geração de documentação de desempenho desta função.
(3) Reset 1. A função operou da maneira pretendida? Se não, por quê?
2. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
(4) Ajuda
1. A função operou da maneira pretendida? Se não, por quê?
2. As informações apresentadas ao usuário são suficientes?
3. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
Fonte: Autor (2018).
Tabela 8 - Questionamentos para avaliação do plug-in de desempenho lumínico
Seção Questionamentos
(1) Gerar
Grid
1. A função operou da maneira pretendida? Se não, por quê?
2. O input de informações climáticas é suficiente? Alguma informação necessária não
foi considerada? Se sim, qual(is)?
3. O input de informações geométricas e de materiais é suficiente? Algum parâmetro
necessário não foi considerado? Se sim, qual(is)?
4. Quanto a inserção e configuração de dados de entrada, como isto poderia ser
melhorado?
5. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
(2) Análise
Lux
1. A função operou da maneira pretendida? Se não, por quê?
2. A maneira como a escala de cores é aplicada é adequada? Como poderia ser
melhorada?
3. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
4. Avalie o potencial para geração de documentação de desempenho desta função.
(3) Análise
FLD
1. A função operou da maneira pretendida? Se não, por quê?
2. A maneira como a escala de cores é aplicada é adequada? Como poderia ser
melhorada?
3. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
4. Avalie o potencial para geração de documentação de desempenho desta função.
(4) Reset 1. A função operou da maneira pretendida? Se não, por quê?
2. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
(5) Ajuda
1. A função operou da maneira pretendida? Se não, por quê?
2. As informações apresentadas ao usuário são suficientes?
3. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
Fonte: Autor (2018).
138
Além disso, algumas questões de avaliação geral dos aspectos foram propostas como
uma maneira adicional de efetuar a avaliação. Foram organizadas com escala Likert
de 5 pontos (Tabela 9), visando expressar um intervalo que corresponda à satisfação
ou concordância em relação a um aspecto.
Tabela 9 - Avaliação dos plug-ins por aspectos de uso específicos
Aspecto avaliado Escala (mín - máx)
Dificuldade no uso (1) Muito fácil – (5) Muito difícil
Design na interface (1) Pouco amigável – (5) Muito
amigável
Performance/Velocidade do
programa (1) Lento - (5) Rápido
Clareza das informações
apresentadas (1) Muito baixa – (5) Muito alta
Potencial para suporte à tomada
de decisão (1) Muito baixo – (5) Muito alto
Capacidade de customização
dos inputs (1) Muito baixa - (5) Muito alta
Versatilidade da ferramenta
para diferentes cenários (1) Pouca - (5) Muita
Fonte: Autor (2018).
Após tais questões, há o espaço para alguns tópicos adicionais: o avaliador pode
também relatar se foram encontrados erros ou bugs durante a experiência; pode
mencionar outras sugestões para o desenvolvimento da ferramenta – que não
tenham sido abordadas nas questões; e sugestões para o questionário de avaliação
em si – para melhorar o próprio mecanismo de avaliação.
A organização de um questionário com estas características permite um grau de
padronização das perguntas que poderá ser reaplicado em outras ferramentas, em
estudos futuros. Além disso, possibilita que este seja encaminhado por meio de
formulários online ou realizado pessoalmente, como foi o caso do presente estudo.
7.2 Experiência de entrevista
O processo de aplicação do questionário foi feito por meio de entrevistas realizadas
no mês de maio de 2018, nas dependências da Faculdade Meridional Campus Passo
Fundo, após a completude da etapa de desenvolvimento das ferramentas projetadas.
Seguindo os critérios metodológicos, foi necessário contatar profissionais com
experiência em relação às temáticas específicas – desempenho acústico e desempenho
lumínico. Para possibilitar ao menos um processo completo de avaliação dos plug-ins
139
com o mecanismo desenvolvido, em dois momentos separados, foi convidada para
responder o questionário do plug-in de desempenho acústico, a prof. Dra. Elvira
Lantelme, e para o plug-in de desempenho lumínico, a prof. Dra. Luciana Fernandes,
ambas docentes do PPGEC IMED (Programa de Pós-Graduação em Engenharia Civil
da Faculdade Meridional).
Cada experiência de avaliação durou aproximadamente um período de uma hora,
seguindo as definições metodológicas, com demonstração e explicitação do
funcionamento esperado de cada funcionalidade programada (Cause-Effect Graph),
seguido pela exploração da interface e testes em diferentes cenários (State-
Transitioning Test) de modo a possibilitar que a abordagem Black Box seja utilizada na
pesquisa a partir de usuários sem conhecimento acerca da programação interna ou
estruturação das rotinas dos artefatos (KHAN, 2011).
Após a experiência de demonstração e exploração da interface, foi realizado o
preenchimento do questionário da respectiva disciplina, por meio de uma entrevista
cujo áudio dos relatos de cada avaliadora foi gravado. A transcrição do áudio foi
então feita, enviando as respostas relatadas para um formulário online, onde foram
sintetizados os principais tópicos relatados em cada funcionalidade dos plug-ins, de
modo a manter a objetividade da apresentação do que foi levantado, conforme o item
seguinte deste capítulo.
7.2.1 Discussões e feedback – Plug-in I
Nesta seção, os principais resultados coletados com a transcrição do áudio gravado
durante as entrevistas são apresentados em relação a cada funcionalidade para
desempenho acústico, e algumas possibilidades de trabalhos futuros são explicitadas.
Em relação à função de cálculo do índice de redução sonora (Figura 75), a discussão
apontou para necessidade de melhorias na organização da maneira como
informações de fabricantes são inseridas. Como no atual estado do plug-in tais
informações são configuradas pelas famílias de paredes e esquadrias, é necessária
uma preparação prévia destes elementos pelo usuário por meio da configuração dos
parâmetros, conforme disposto no item 6.1.2 deste trabalho. Com este relato, versões
subsequentes do plug-in podem ser programadas com novas maneiras de configurar
os dados de fabricante. Analisa-se uma alternativa por meio de interface ou janela
pop-up onde o usuário possa carregar valores ou alterar existentes.
Um aspecto positivo levantado foi a boa integração com funções já existentes do
Revit, como ferramentas de dividir e unir paredes, configurações de camadas e a aba
de anotações, que permite expressar o valor dos parâmetros.
140
Figura 75 - Quadro de respostas para a função (1) Calcular Rw
Respostas ACS – (1) Calcular Rw
1. A função operou da maneira pretendida? Se não, por quê?
Operou da maneira pretendida.
2. O input de informações é suficiente? Algum parâmetro necessário para o cálculo não foi
considerado?
Todos os parâmetros necessários para calcular foram considerados.
3. Quanto a inserção e configuração de novos materiais e sistemas construtivos, como isto poderia
ser melhorado?
Na organização destas informações. Quando há vários fabricantes, com várias características de
materiais, deve-se pensar em como isso pode ser organizado.
4. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
Os valores das medições são expressos com precisão de duas casas após a vírgula, o que é
desnecessário para decibel.
Fonte: Autor (2018).
Em relação à função de verificação dos valores de índice de redução sonora (Figura
76), destacou-se a necessidade de alteração no valor de desempenho referencial
quando a função é acionada. A pré-configuração deste valor para o nível Mínimo ao
invés do Intermediário tornaria a ferramenta mais intuitiva, pois o usuário
inicialmente seria direcionado ao simples atendimento da norma, ao invés de estar
submetido a este acrescido da margem do nível Intermediário.
Figura 76 - Quadro de respostas para a função (2) Verificar desempenho
Respostas ACS – (2) Verificar desempenho
1. A função operou da maneira pretendida? Se não, por quê?
Funcionou.
2. A maneira como a escala de cores é aplicada (variações de um valor definido) é adequada? Como
poderia ser melhorada?
A maneira como as cores são distribuídas na escala é adequada, porém, o valor alvo inserido pelo
usuário deveria ser modificado do médio (intermediário) para o valor mínimo. Além disso, ser pré-
configurado para esta opção desde o início.
3. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
Pensando na questão visual, a opção de ativar e desativar os tags e cotas, pois uma coisa é o projetista
tomando decisões durante o projeto, outra é apresentar para o cliente. Uma função para esconder
informações desnecessárias ajudaria nisso, criando uma instância exclusiva para acústica no Revit, que
facilmente poderia ser retornada para o projeto de arquitetura.
4. Avalie o potencial para geração de documentação de desempenho desta funcionalidade.
A função é eficiente e muito importante para automatizar a documentação.
Fonte: Autor (2018).
Em relação à função Reset (Figura 77), durante a apresentação, notou-se que esta
também apaga os valores existentes nas famílias, o que pode tornar o processo de
cálculo de diferentes alternativas algo repetitivo e que poderia ser melhorado, com
isso, foi sugerido ocultar as informações, ao invés de apagá-las. Embora o Revit conte
com algumas funções para esconder certos elementos nas vistas, o uso desta opção
141
pode se tornar trabalhoso quando há muitos elementos e diferentes filtros a serem
aplicados, portanto, analisa-se a possibilidade de programar rotinas que manipulem
a visibilidade de elementos na vista do Revit.
Figura 77 - Quadro de respostas para a função (3) Reset no plug-in para desempenho acústico
Respostas ACS – (3) Reset
1. A função operou da maneira pretendida? Se não, por quê?
Funcionou.
2. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
Como discutido antes, apenas ocultar e não deletar permanentemente as informações.
Fonte: Autor (2018).
A função de ajuda (Figura 78) foi criticada por apresentar informações insuficientes e,
portanto, haveria espaço para muitas melhorias. Como o pacote de configurações de
interfaces Data-shapes para Dynamo (discutido no Capítulo 3) possibilita o
carregamento de arquivos, imagens, pdfs, links para websites e outros, muitas das
sugestões poderiam ser facilmente incorporadas por meio da inclusão de
informações que possam ser apresentadas para o usuário por quaisquer das maneiras
citadas.
Figura 78 - Quadro de respostas para a função (4) Ajuda no plug-in para desempenho acústico
Respostas ACS – (4) Ajuda
1. A função operou da maneira pretendida? Se não, por quê?
Funcionou.
2. As informações apresentadas ao usuário são suficientes?
A função atualmente está muito simples. Consultar tabelas não é tão interessante para o usuário, a não
ser para quem estiver começando a estudar a norma, como estudantes, com um fim didático.
3. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
Colocar outras informações: uma sequência de como operar o plug-in, um manual de ajuda de como
usar as funções, explicação acerca das cores usadas, como avaliar o Rw, como configurar novos
materiais.
Fonte: Autor (2018).
Após a realização da parte narrativa do questionário, foram apresentadas as
perguntas de escala Likert, referidas aos aspectos gerais do plug-in. Contudo, não é
possível realizar uma avaliação quantitativa eficaz de tais aspectos com apenas um
respondente, portanto, até o presente estudo, esta seção do questionário possui
caráter complementar e só poderá ser aplicada como avaliação em trabalhos futuros,
com maior quantidade de avaliadores.
Segundo a avaliadora, utilizando a escala Likert de 5 pontos, onde o índice 1 é a pior
classificação e o índice 5 é a melhor, o plug-in é de fácil uso (índice 5); possui uma
interface amigável (índice 4); funciona de maneira rápida (índice 5); conta com
informações muito claras (índice 5); e de alto potencial para o suporte à tomada de
142
decisão (índice 4). Contudo, possui baixa capacidade de customização dos inputs
(índice 2), sobretudo em relação aos materiais de fabricantes; e sua versatilidade em
diferentes cenários é incerta pois necessita de aplicação em projetos reais (índice 3).
Em relação a erros ou bugs durante a avaliação, ocorreram apenas problemas
relacionados à plataforma Revit e não à programação do plug-in.
Como sugestão para o formulário de questões, a avaliadora relata que seria
interessante submeter os plug-ins à avaliação por projetistas que estejam realizando
processos de comprovação de desempenho, para permitir que utilizem a ferramenta
e possam dar outras sugestões advindas do tempo de uso. Contudo, ressalta que, o
uso do plug-in torna-se limitado, devido ao fato de que a transição entre ferramentas
de desenho 2D para BIM ainda está presente nos processos de projeto de muitos
profissionais, algo que se torna mais complicado quando se inclui a necessidade de
encontrar profissionais com conhecimentos de programação.
7.2.2 Discussões e feedback – Plug-in II
Assim como na seção anterior, são apresentados os principais resultados coletados
com a transcrição do áudio gravado durante as entrevistas em relação às funções do
plug-in de desempenho lumínico, com algumas possibilidades de trabalhos futuros.
Em relação à função de geração do grid nos ambientes (Figura 79), a avaliadora
afirma que, embora tenha funcionado adequadamente em relação aos inputs
climáticos, possui algumas melhorias necessárias na interface. Além disso, não
contemplou a inserção de configurações físicas e óticas de materiais. Como uma
alternativa para adicionar estas propriedades, analisa-se a manipulação de
parâmetros de superfícies já presentes nos materiais do Revit. Contudo, tais inclusões
também estão sujeitas a atualizações dos pacotes Ladybug e Honeybee para Dynamo,
que continuamente adicionam novas possibilidades para os programadores na
configuração de tais parâmetros e podem, portanto, levar a maneiras mais adequadas
de programar isto.
Outra crítica foi o tempo necessário para execução da função, que necessitava de um
período entre 2 e 4 minutos para cada interação e, portanto, limitava o potencial da
ferramenta para analisar diversos cenários de forma rápida. Em relação a isto, cabe o
refinamento do algoritmo ao longo do tempo em desenvolvimentos futuros, visando
otimizar a programação. Como uma maneira de possibilitar agilizar as análises, a
avaliadora sugeriu adicionar uma opção que calcule a iluminância ou fator de luz
diurna apenas no ponto central do ambiente analisado, possibilitando assim, uma
avaliação preliminar rápida. Além disso, sugeriu programar a criação de objetos de
143
anotação do Revit já no centro de tais ambientes, indicando o horário e dia analisado,
o tipo de análise, o valor encontrado e se atende ao desempenho Mínimo.
Figura 79 - Quadro de respostas para a função (1) Gerar Grid
Respostas LUM – (1) Gerar Grid
1. A função operou da maneira pretendida? Se não, por quê?
Funcionou.
2. O input de informações climáticas é suficiente? Alguma informação necessária não foi
considerada? Se sim, qual(is)?
O input é suficiente, pois depende da qualidade e interpretação do arquivo EPW.
3. O input de informações geométricas e de materiais é suficiente? Algum parâmetro necessário não
foi considerado? Se sim, qual(is)?
Não está tão detalhado como a norma exige devido ao espaçamento do grid em relação às paredes do
ambiente. É preciso respeitar os 50 cm de distância dos cantos, pois, dependendo da geometria, em
ambientes pequenos pode haver diferença. Recomenda-se verificar se a forma como o plug-in cria a
malha gera diferença nos resultados.
Não foi incluso nenhum tipo de input de materiais, sendo os parâmetros necessários a considerar:
materiais opacos e transparentes, fatores físicos e óticos que influenciem na iluminação interna, cores
de superfícies. Recomenda-se olhar o manual de softwares semelhantes como o DaySIM.
4. Quanto a inserção e configuração de dados de entrada, como isto poderia ser melhorado?
Ao invés dos sliders, utilizar uma ferramenta de calendário para que o usuário defina o dia e mês, ou
um campo de texto.
Possibilitar escolher diretamente o solstício de verão ou inverno, e o equinócio de outono ou
primavera, semelhante a como foi feito com os horários da norma – botões de rádio ou checkbox.
5. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
Uma opção de realizar o cálculo somente no ponto central dos ambientes.
Colocar elementos de legenda já no momento de geração do grid.
Configurações de brise para poder visualizar como este iria influenciar no sombreamento, entre
outros.
Fonte: Autor (2018).
Na função de análise de iluminâncias (Figura 80), foram ressaltados aspectos
estéticos como espaçamento dos grids e a escolha das cores. Estes podem ser
configurados diretamente no Dynamo, possibilitando que em trabalhos futuros,
sejam criados grids com mais componentes e intervalos de filtros de vista melhor
definidos, sem consequências para o funcionamento correto da ferramenta. A opção
de criação de escala de cores automatizada também foi levantada, pois atualmente
não é criada na programação, necessitando ser feita separadamente, e por ser um
elemento de relatório que auxilia na clareza das infomações apresentadas.
144
Figura 80 - Quadro de respostas para a função (2) Análise Lux
Respostas LUM – (2) Análise Lux
1. A função operou da maneira pretendida? Se não, por quê?
Funcionou.
2. A maneira como a escala de cores é aplicada é adequada? Como poderia ser melhorada?
A escala de cores poderia ter mais divisões, ser mais refinada, com um grid menor.
3. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
A opção de criar um elemento de escala de cores correspondente à análise, automaticamente no Revit.
4. Avalie o potencial para geração de documentação de desempenho desta funcionalidade.
Possibilita gerar alguns relatórios de desempenho de forma automatizada.
Fonte: Autor (2018).
A função de análise do fator de luz diurna (Figura 81) infelizmente não funcionou
nos ambientes selecionados durante o processo avaliativo, com os valores
aparecendo zerados no grid gerado. Contudo, foi mostrado um exemplo em um
arquivo do Revit onde foi explicada a maneira como os valores são calculados. Cabe
revisar a programação em estudos futuros para possibilitar a avaliação adequada
desta função em específico. As sugestões para a função foram semelhantes às da
função anterior.
Figura 81 - Quadro de respostas para a função (3) Análise FLD
Respostas LUM – (3) Análise FLD
1. A função operou da maneira pretendida? Se não, por quê?
Não funcionou, os valores do parâmetro ficaram zerados após a geração do grid.
2. A maneira como a escala de cores é aplicada é adequada? Como poderia ser melhorada?
Como funciona de forma semelhante, idem às sugestões da função anterior.
3. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
Idem às sugestões da função anterior. Corrigir texto, de “Fator de luz diária” para “Fator de luz
diurna” na interface.
4. Avalie o potencial para geração de documentação de desempenho desta funcionalidade.
Não foi possível avaliar.
Fonte: Autor (2018).
Para a função Reset (Figura 82), de forma semelhante ao ocorrido na avaliação do
plug-in de desempenho acústico, a avaliadora sugeriu que, ao invés das informações
geradas serem apagadas, poderiam apenas ser ocultadas, para que possam ser
revisitadas em um momento futuro pelo usuário. Uma alternativa pensada para
tornar isto possível com a programação é através da manipulação dos layers de
visibilidade do Revit, possibilitando que diversas análises de iluminância ou FLD
sejam sobrepostas e verificadas simultaneamente ocultando elementos de
determinados horários – algo que, na programação atual, só é possível copiando
elementos de ambientes no Revit e realizando análises separadas.
145
Figura 82 - Quadro de respostas para a função (4) Reset para o plug-in de desempenho lumínico
Respostas LUM – (4) Reset
1. A função operou da maneira pretendida? Se não, por quê?
Funcionou.
2. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
Ao invés de apagar completamente a geometria do grid, apagar apenas os valores deste ou ocultar os
elementos, visto que, segundo a explicação, a geração de geometria é o que leva mais tempo.
Fonte: Autor (2018).
Em relação à função de ajuda (Figura 83), também foi destacada a simplicidade das
informações atualmente apresentadas, sendo possível adicionar um manual de uso,
informações didáticas acerca de conceitos como iluminância e FLD, outras
informações de referencial normativo além das duas tabelas, e o contato com o
desenvolvedor.
Figura 83 - Quadro de respostas para a função (5) Ajuda para o plug-in de desempenho lumínico
Respostas LUM – (5) Ajuda
1. A função operou da maneira pretendida? Se não, por quê?
Funcionou.
2. As informações apresentadas ao usuário são suficientes?
Não. É importante também colocar os conceitos por trás das análises. Definir FLD e iluminância, como
as análises são feitas, e apresentar referências bibliográficas para outros trabalhos. Colocar tabelas
retiradas da norma ao invés do catálogo CBIC.
3. Alguma opção adicional deveria ser incluída nesta funcionalidade? Se sim, qual?
Uma opção que mostre o passo-a-passo de como usar a ferramenta seria interessante.
Colocar publicações próprias e uma aba de “Sobre” para os plug-ins, para que alunos, pesquisadores e
projetistas possam entrar em contato com o desenvolvedor.
Fonte: Autor (2018).
Quanto aos aspectos avaliados em escala Likert de 5 pontos, sendo o índice 1 a pior
classificação e o índice 5 a melhor, a avaliadora classificou o plug-in como de fácil
uso (índice 4); com design da interface amigável, apesar de melhorias necessárias (4);
operando com velocidade das funções consideravelmente lenta (índice 1),
demorando vários minutos para análise. Em relação à clareza das informações,
indiferente (índice 3); com potencial para suporte à decisão bom (índice 4), devido às
representações visuais e cores. A capacidade de customização dos inputs foi
considerada baixa (índice 2), devido ao fato de que as propriedades físicas e óticas
dos materiais não foram contempladas.
Em relação à versatilidade da ferramenta para aplicação em diversos cenários, foi
classificada como alta (5). A avaliadora ressaltou que a ferramenta tem potencial para
temáticas como etiquetagem de eficiência energética e certificações, seria possível
atrelar outras informações ao mecanismo da programação, como pontuação de
146
créditos para LEED, sombreamento, outros tipos de análises horárias e geração de
relatórios automatizados.
Em relação ao formulário de avaliação, a avaliadora sugeriu condicionar o envio do
questionário aos conhecimentos do entrevistado, estabelecendo previamente que
perguntas serão enviadas conforme as atribuições do respondente – projetista ou
pesquisador.
7.3 Considerações finais sobre a avaliação
A avaliação, de modo geral, foi muito benéfica para levantar sugestões e maneiras de
como melhorar os plug-ins, podendo utilizar do conhecimento específico e
experiência de profissionais para aperfeiçoar o desenvolvimento dos plug-ins. Isto
ressalta a importância da interdisciplinaridade também na programação, pois
permite que o projetista que desenvolve suas próprias ferramentas busque caminhos
alternativos pela ótica do usuário ou do especialista.
A avaliação dos plug-ins também possui grande importância do ponto de vista
metodológico, pois permite verificar se os artefatos do tipo instanciação projetados
estão se comportando da maneira como foram pensados, possibilitando a criação de
mecanismos adaptáveis às diferentes particularidades de cada artefato para
compreender se o que foi programado está realmente atendendo seus objetivos
iniciais.
147
8. CONCLUSÕES
Neste capítulo final, são apresentadas as principais discussões sobre a experiência da
pesquisa. Inicialmente são resgatados os objetivos e são apontadas as contribuições e
percepções gerais sobre a condução do trabalho no desenvolvimento e avaliação dos
artefatos do tipo instanciação. Então, nos sub-items subsequentes, são apresentados:
(8.1) Diretrizes para o desenvolvimento de plug-ins em software BIM – onde o
artefato consolidado da pesquisa é descrito; (8.2) Generalização para classe de
problemas – onde são apontadas similaridades do emprego do método em outros
possíveis cenários; (8.3) Reflexões e posicionamento – onde é apresentada a opinião e
posicionamento crítico acerca da experiência de programar, das ferramentas
utilizadas e da Norma de Desempenho; e (8.4) Recomendações para trabalhos
futuros.
Os processos de projeto em arquitetura e engenharia requerem cada vez mais
informações interdisciplinares na tomada de decisão. Embora muitas ferramentas
possibilitem automatizar etapas dos projetos por meio dos softwares, a informação
precisa estar contextualizada e ser efetivamente usada em simulações, verificações e
análises, de modo a impactar a tomada de decisão do projetista. O uso da
programação em softwares BIM permite que esta não seja dedicada apenas à geração
de formas arquitetônicas, mas também ao gerenciamento de dados e relações
semânticas do modelo.
Neste trabalho foi apresentada uma pesquisa voltada à compreensão do cenário de
inovação na arquitetura e engenharia por meio do desenvolvimento de soluções
customizadas a partir da programação pelos projetistas. Para emular o cenário e
atender o objetivo, foram desenvolvidos dois plug-ins para o software BIM Revit, no
intuito de possibilitar ampliar as funções da plataforma em relação a um problema
específico: o atendimento de requisitos da Norma de Desempenho Brasileira.
A partir da experiência de programação pelo pesquisador, foi possível romper
algumas das barreiras de abstração das plataformas e das funcionalidades básicas
para atender os requisitos estipulados. Assim, como principais resultados, tem-se o
desenvolvimento e avaliação das ferramentas: plug-in para estimativa de
desempenho acústico de vedações verticais; e para estimativa da iluminância natural
no interior de ambientes de uma edificação.
No cenário acadêmico, este trabalho contribuiu também para pesquisas voltadas à
metodologia de projeto, e que utilizem o método Design Science Research.
Adicionalmente, contribuindo para estudos relacionados à BIM, e ao uso da
programação como uma competência para o futuro da profissão, bem como para
148
pesquisas relacionadas à Norma de Desempenho Brasileira – nas temáticas de
desempenho acústico e lumínico.
Em relação ao cenário profissional, na prática projetual, as contribuições foram
apresentadas na forma da publicação das duas ferramentas funcionais, as quais
poderão ser utilizadas para alavancar o processo de comprovação de desempenho
por meio da análise de projetos em softwares BIM – na verificação e simulação de
requisitos.
Em relação às percepções gerais do método Design Science Research, concluiu-se que
este permitiu estruturar uma pesquisa de caráter prático para que esta possua
vínculos com conhecimento teórico, através da definição das etapas de condução da
pesquisa.
O desenvolvimento das ferramentas para atendimento aos requisitos, embora algo
desafiador, possibilitou ao pesquisador passar pelos processos de aprendizado e
reflexão de um projetista, buscando resolver problemas específicos e, inicialmente,
inacessíveis pelas funções básicas das ferramentas disponíveis. Foi um processo que
envolveu, dentre outros aspectos, a colaboração com outros programadores por meio
dos fóruns e repositórios online, a disponibilidade de material e documentação sobre
funções do Dynamo e Revit, e a disponibilidade de tempo dedicado para
experimentação e aplicação do conhecimento adquirido no desenvolvimento dos
plug-ins. O emprego da programação permitiu conhecer o contexto dos requisitos os
quais se buscou automatizar: desde a maneira como são calculadas as variáveis até o
sequenciamento lógico necessário para transformá-las em subsídios para tomada de
decisões. Informações que não são facilmente absorvidas apenas por meio de leitura
de normas ou do uso de uma planilha de cálculo pronta.
A necessidade de programar uma ferramenta induz o projetista e/ou pesquisador a
compreender profundamente como se dão os processos de verificações e simulações.
Analisa-se o motivo de certas informações serem necessárias em cada etapa, e qual
sua finalidade, assim, é possível também ter uma opinião sobre a maneira como as
regras são impostas e refletir acerca das arbitrariedades de normas e regulações de
projetos.
Em relação à etapa de avaliação das ferramentas, foi feito uma aplicação inicial com
dois profissionais pesquisadores, com conhecimento das áreas específicas,
adicionando a perspectiva de especialistas e sua visão de como melhorar um
processo. Assim, além da busca pelo conhecimento específico para solucionar o
problema durante a etapa de desenvolvimento, houve a busca por possíveis
melhorias nas ferramentas – atributos que não foram inicialmente considerados. Em
relação aos outputs esperados, as rotinas funcionaram da maneira como foram
149
descritas, na maioria das situações, porém, com espaço para muitas melhorias e
correções, que não seriam detectadas se não fosse realizada a avaliação.
8.1 Diretrizes para o desenvolvimento de plug-ins em software BIM
As diretrizes para o desenvolvimento de plug-ins podem ser interpretadas como o
artefato central da pesquisa, que somente foi identificável após a experiência de
desenvolvimento e avaliação de suas instanciações – na forma da programação dos
plug-ins. Representando, assim, o entendimento do autor com base nos experimentos
realizados.
Tais diretrizes são guidelines para auxiliar projetistas e pesquisadores na
compreensão do processo de criação de ferramentas para problemas específicos, e
apresentam-se na forma de uma série de procedimentos sugeridos para a
consolidação de ferramentas customizadas em software BIM, seguidos por
questionamentos direcionadores. Em outras palavras, as diretrizes propostas nesse
trabalho consistem na descrição ou esboço de um método para o desenvolvimento de
plug-ins em softwares BIM, as quais estão descritas abaixo:
1. Definir um software BIM e obter amplo conhecimento acerca de suas
funções básicas: primeiramente, é necessário identificar funcionalidades já
existentes de um software BIM – Revit, ArchiCAD, AECOsim, Vectorworks e
outros. Para isso, é necessário aprender sobre como o ambiente do software
opera e de que maneiras pode ser programado. Analisando questões como:
• Qual software BIM será customizado?
• O que o software já realiza e não precisa ser programado?
• Como as funções básicas podem ser combinadas?
2. Encontrar um problema que possui potencial para ser automatizado no
software BIM: consiste em encontrar particularidades de projeto que
necessitem de automatização; verificar a presença de um processo que não
pode ser atendido simplesmente nas funcionalidades básicas, ou que seja
severamente limitado se não for implementada a programação, ou que possua
um potencial ainda não descoberto. No presente estudo, foi utilizado um
survey para direcionar a criação de plug-ins para a Norma de Desempenho.
• O que precisa ser automatizado, ou que decisões de projeto necessitam
de suporte?
• Quais as particularidades do processo que não são atendidas pelas
funcionalidades básicas?
• O problema envolve um processo moroso, trabalhoso ou pouco
integrado com outras ferramentas?
150
3. Examinar a necessidade de programação: a partir do problema identificado, o
projetista deve realizar uma reflexão crítica sobre a real necessidade e
relevância de programar a ferramenta. Deve também verificar ferramentas
semelhantes e repositórios de plug-ins, identificando o que já existe e o que
ainda pode ser melhorado ou desenvolvido.
• É algo que necessita obrigatoriamente de inserção no âmbito de BIM,
ou poderia ser feito em softwares simplificados?
• Existem plug-ins ou outros softwares que já realizam a tarefa?
• As soluções existentes são suficientes para as particularidades?
• As soluções existentes são integradas no processo BIM?
• A ferramenta pretendida irá auxiliar na automatização do processo ou
no suporte à tomada de decisão?
4. Obter conhecimento acerca da extensão de programação visual do software
BIM: com a decisão de programar uma ferramenta para um software BIM é
necessário dedicar tempo para aprender a respectiva extensão de VPL:
Grasshopper para ArchiCAD, GenerativeComponents para AECOsim,
Marionette para Vectorworks, ou Dynamo para Revit. Recomenda-se buscar
materiais em repositórios online, participar de discussões em comunidades de
desenvolvedores e experimentar com as funções iniciais e funções
customizadas (Custom Packages) da extensão escolhida.
• Quais são as possibilidades acrescentadas pela extensão de VPL?
• Como as barreiras de funções básicas podem ser ultrapassadas?
• Quais são as comunidades de usuário que fomentam o aprendizado
sobre a extensão VPL?
5. Examinar a viabilidade de programação: após adquirir conhecimentos iniciais
sobre o que a extensão de VPL pode fazer, é recomendado pesquisar o que já
foi feito em áreas relacionadas ao tema do problema, para adquirir um
repertório de como as soluções são criadas com a extensão VPL. Nesta etapa,
também é necessária uma segunda reflexão crítica acerca de se é possível
programar a solução para o problema. Sugere-se realizar um levantamento
sobre informações referenciais como tabelas, equações e classificações.
• A extensão de VPL escolhida possui funcionalidades suficientes para o
problema?
• O processo a ser programado está documentado em referências como
normas ou regulamentos?
• As regras e variáveis do problema são objetivas e de clara
interpretação?
6. Projetar funcionalidades da ferramenta e definir métricas: consiste em
elencar funções e definir fluxogramas de funcionamento pretendido para as
151
ferramentas, expor que informações devem ser inseridas inicialmente,
organizar as equações ou passos necessários para que haja um resultado
explícito ao final da execução de cada função. Outro ponto é a definição de
métricas que demonstrem que o plug-in a ser programado contribui na
resolução do problema. É necessário também ter um amplo conhecimento
acerca do encadeamento lógico do problema e das diversas facetas
relacionadas à sua teoria. Nesta etapa, também deve ser definido se o plug-in
irá ser apenas utilizado pelo projetista/pesquisador, ou se seu uso será
estendido para outras pessoas.
• Quais os objetivos da ferramenta?
• Como a ferramenta efetivamente auxiliará na automatização ou tomada
de decisão? Como isto é mensurado?
• Como a ferramenta está integrada no processo BIM?
• Quais são os inputs e outputs de cada uma das funções?
• Qual o desempenho desejado para a ferramenta ou plug-in? Ou ainda,
o que irá determinar que a solução foi satisfatória?
• O plug-in será de uso pessoal do programador ou será disponibilizado
para outras pessoas? Se sim, quais as definições iniciais relativas à
interface de usuário?
7. Programar a primeira versão da ferramenta: a partir do projeto das
funcionalidades, este processo essencialmente criativo consiste na criação das
primeiras rotinas em um estágio inicial. Durante o desenvolvimento da
ferramenta, recomenda-se também iniciar o aprendizado gradativo sobre TPL
para possibilitar a interpretação de códigos desenvolvidos por outros
programadores.
• Como o projeto será implementado por meio de programação?
• Existem Custom Packages ou similares que podem auxiliar na
programação de rotinas do plug-in?
8. Implementar a solução em um ambiente controlado: consiste em um período
de avaliação do plug-in ou ferramenta pelo próprio programador, de modo a
verificar erros na estruturação interna e apontar melhorias imediatas para
atender o projeto de funcionalidades. Isto pode ser feito por meio da inserção
de inputs conhecidos, cujo resultado pode ser facilmente verificado ou
antecipado. Pode ser realizada concomitantemente à etapa de programação.
• O que não foi previsto no projeto das funcionalidades e precisa ser
melhorado?
• O projeto está sendo respeitado nas funcionalidades? O que foi alterado
e por quê?
152
• A solução é satisfatória conforme as métricas inicialmente
estabelecidas? Os resultados são precisos em relação ao que foi
programado?
9. Desenvolver uma interface de usuário: conforme definido no projeto das
funcionalidades, consiste em propiciar a utilização do plug-in pelo próprio
programador ou por terceiros, que podem ser projetistas ou partes
interessadas no processo BIM, sem conhecimento do funcionamento interno.
Recomenda-se utilizar organizadores de rotinas como o Dyno Browser,
Dynamo Player ou similares – conforme o software BIM escolhido.
• Quais as necessidades de interface de uma ferramenta destinada
apenas a uso particular?
• Outros projetistas irão utilizar a ferramenta desenvolvida? Se sim,
possuem conhecimento acerca do funcionamento da interface VPL?
• Que informações facilitarão o uso da ferramenta por terceiros sem
conhecimento de sua estruturação interna?
10. Avaliar a ferramenta junto a profissionais com conhecimento sobre o tema
do problema: recomenda-se desenvolver mecanismos de avaliação para cada
funcionalidade, como exemplificado no questionário de avaliação da presente
pesquisa (Capítulo 7). Isto é necessário para evidenciar feedback, a partir de um
terceiro, evidenciando se as funções projetadas estão atendendo seu propósito.
• Quem pode avaliar a ferramenta? É necessário o conhecimento em
programação para avaliá-la?
• Como será feita a avaliação da ferramenta em relação às métricas
inicialmente estabelecidas?
• De que forma serão registrados os resultados da avaliação para que
possam ser incorporados no futuro?
11. Ponderar sobre a aplicabilidade da solução: após a primeira experiência de
desenvolvimento e avaliação, é necessário elencar oportunidades de melhoria,
levantar problemas a serem corrigidos, novas funções a serem incorporadas,
entre outros fatores. Após esta etapa, o projetista/pesquisador deve ponderar
sobre o futuro do desenvolvimento da ferramenta e, se julgar necessário,
retornar a uma etapa anterior e iniciar um novo ciclo de criação.
• No estado atual, a ferramenta atingiu os objetivos propostos no projeto?
• Se sim, como a ferramenta pode ser divulgada?
• Quais as melhorias necessárias em relação à interface?
É importante ressaltar que as diretrizes propostas não foram incorporadas apenas no
desenvolvimento da pesquisa atual, mas se estenderam indiretamente às outras
disciplinas do mestrado em Arquitetura e Urbanismo. Programar ferramentas para
153
temas específicos foi gradativamente tornando-se parte da abordagem do
pesquisador para solucionar problemas, com aplicações também nas áreas de
climatologia, estudos solares, fabricação digital e prototipagem, layout de parques,
orçamentos, instalações elétricas e hidráulicas, bem como para avaliação pós
ocupação – onde foi desenvolvida uma ferramenta para integrar variáveis de
satisfação de usuários no modelo BIM.
Isto permite pensar na possibilidade de implementação das diretrizes no âmbito do
ensino: ponderar sobre a possibilidade de aproveitamento destas para a criação de
“caixas de ferramentas” desenvolvidas pelos próprios alunos, com base em uma
necessidade específica identificada em determinada disciplina. Isto permite analisar
o desenvolvimento da competência emergente de programar a partir da solução de
problemas.
8.2 Generalização para classe de problemas
Conforme o delineamento metodológico, após a experiência de desenvolvimento e
avaliação dos plug-ins, é necessário refletir sobre a aplicabilidade do que foi feito em
outros cenários. Ao longo do trabalho, é apresentado um cenário amplo de criação de
soluções pelos projetistas para uma diversidade de situações que foram solucionadas
com programação. Nesta seção, busca-se refletir, a partir do que foi delimitado pelo
tema específico, se existem características semelhantes com a classe de problemas
definida – tomada de decisão em projetos, que tornam possível a identificação e
reaplicação de tais similaridades em outros cenários.
Primeiramente, foi necessário identificar uma oportunidade na temática específica: a
identificação de um problema de relevância que não pode ser facilmente resolvido
com um software já existente, ou por maneiras simplificadas como planilhas de
cálculo ou funções básicas das plataformas. Isto é necessário para dar ênfase na
importância de algo ser programado.
Em relação às necessidades para reaplicação da experiência, é imprescindível a
presença de parâmetros disponíveis e regras bem definidas para viabilizar sua
programação no software BIM. Se os parâmetros não estiverem inicialmente
disponíveis, mas existirem maneiras de calculá-los, com base na interdependência ou
equivalência de outros parâmetros presentes, o processo ainda é possível.
Alguns exemplos de estudos envolvendo criação de ferramentas para finalidades
semelhantes à abordada nesta pesquisa foram apresentados nos Capítulos 3 e 4,
durante a revisão bibliográfica. Analisa-se a oportunidade de emprego da
154
programação visual para resolver problemas de natureza similar: que possuam
parâmetros e regras definidos, ou um referencial a ser atingido.
Assim como foram desenvolvidas ferramentas para auxiliar na tomada de decisão
perante os requisitos de desempenho acústico e lumínico da Norma de Desempenho
Brasileira, poderiam ter sido programadas funcionalidades voltadas para, por
exemplo, requisitos de acessibilidade, resistência ao fogo, conforto térmico e impacto
ambiental. Bem como para outras formas de regras, por exemplo, o atendimento de
requisitos de uma certificação ambiental, o cumprimento de uma legislação
municipal ou estadual, o dimensionamento condicionado de elementos, e outras
normas específicas.
Para os outros requisitos do desempenho, conforme pontuado no Capítulo 4, o foco
necessário está na criação de ferramentas que possibilitem a articulação de
informações de fabricantes, ou a caracterização de sistemas construtivos, para
possibilitar a geração de documentação por meio de verificações e estimativas.
Nas certificações ambientais, como muitos dos requisitos são verificações do que está
definido em projeto, dados quantitativos podem ser automatizados, e parte dos
qualitativos pode ser elucidada por meio de conjuntos de regras. A programação de
requisitos em um software BIM permite, além de auxiliar na tomada de decisão,
possibilita implantar estratégias para atendimento de créditos da certificação
ambiental conforme o que é almejado pelas partes interessadas.
Em relação à automatização de um modelo conforme requisitos de legislação
municipal ou estadual de edificações – por exemplo, um código de obras, é possível
programar a verificação controlada de um modelo BIM, realizar cálculo de áreas de
janelas, dimensões mínimas, espaçamentos e outras regras, potencializando novas
maneiras de pensar a composição inicial da edificação, para flexibilizar os processos
de definição de ambientes, aberturas e outras situações.
Para o dimensionamento condicionado de componentes, há também a presença de
componentes BIM adaptivos - famílias de objetos que se adaptam a parâmetros
inseridos, assim, é possível condicionar a forma ou o comportamento dos
componentes BIM a uma série de regras. Um exemplo disso é o posicionamento
automatizado de painéis solares, que pode ser programado conforme a orientação
solar, ou brises móveis que se adaptam às condições climáticas, rotacionando ou
movimentando seus componentes conforme a radiação solar.
Quanto à adequação em relação a outras normativas, analisa-se potencial do uso da
programação para cálculo estrutural e otimização de seções. Como as informações de
combinações de carregamento e vento são acessíveis por meio do uso de softwares, é
155
possível programar rotinas para automatizar cálculos relativos ao dimensionamento
de estruturas de concreto, aço e madeira, permitindo a definição de elementos
estruturais como treliças ou estruturas complexas de fachada a partir de algoritmos
generativos, form-finding, design evolutivo, entre outros aspectos.
Conclui-se que, desde que as particularidades de tais situações sejam respeitadas, e
de que os parâmetros envolvidos estejam disponíveis ou possam ser capturados
pelos algoritmos de programação visual, é possível ao projetista e/ou pesquisador
desenvolver uma vasta gama de ferramentas voltadas para ampliar a tomada de
decisão do projetista, tendo como consequência, a automatização de muitos
processos a partir de informações referenciais e regras.
8.3 Reflexões e posicionamento sobre a experiência
A competência de programar qualifica o projetista, acrescenta habilidades
compatíveis com as suas novas responsabilidades na era digital e o coloca como o
tomador de decisão, no centro dos processos de informação, permitindo
gradativamente que este liberte-se das limitações de plataformas fechadas e de
softwares comerciais que não atendem todas suas necessidades. Esta circunstância
permite refletir acerca do papel da programação no futuro da profissão do arquiteto
ou engenheiro.
Diante disto, imagina-se o que precisa acontecer, ou alguns dos principais aspectos,
para que a situação do projetista programador se desenvolva. Para isso, alguns
tópicos podem ser levantados:
• A importância das extensões de código aberto, gratuitas e facilmente
acessíveis por estudantes ou pesquisadores, configurando um ambiente que
permita capturar informações com confiabilidade;
• A presença de um problema relevante a ser resolvido, que evidencie a
fragilidade das funcionalidades básicas e desperte insatisfação com as
ferramentas disponíveis para o projetista atualmente;
• A própria criatividade do projetista em pensar o funcionamento de uma
solução, aliada a inspirações de implementações que deram certo;
• Experiência ou conhecimento prévio interdisciplinar, do tema específico do
problema a ser solucionado, e sobre programação, ou ainda, tempo para
aprender esta habilidade;
• E principalmente, a presença de uma comunidade de usuários online,
projetistas em diversos graus de conhecimento acerca de programação VPL e
156
TPL nos softwares BIM, que compartilham suas soluções, atendem às dúvidas
e fomentam o aprendizado dos interessados;
Algumas circunstâncias externas também podem ser levantadas para aumentar o
potencial da programação em softwares BIM por projetistas, conforme as definições
dos Campos BIM (SUCCAR, 2009) apresentados no Capítulo 2. No Campo da
Tecnologia, imagina-se a presença de plataformas robustas e interoperáveis, com
vastas bibliotecas de funcionalidades que podem ser manipuladas por programação,
permitindo remover limitações das próprias extensões VPL e ampliar as situações em
que podem ser usadas.
Em relação ao Campo das Políticas, no ensino, analisa-se a inserção de disciplinas
voltadas para tecnologia no currículo de cursos de arquitetura e engenharia, que
iniciem o processo e demonstrem a importância e potencial de programar soluções
próprias para alunos; nas normas e regulamentos, a presença de regras claras e
transparentes, para que a programação possa ser feita adequadamente e não sejam
encontradas barreiras de subjetividade em requisitos ou critérios.
No Campo dos Processos, analisa-se a necessidade de problemas que necessitem de
programação para serem resolvidos, ou ainda, uma demanda de situações que
necessitem ser otimizadas nos processos BIM.
Além destes tópicos levantados e circunstâncias descritas para propiciar o cenário de
programação de ferramentas, também podem ser feitas reflexões acerca da extensão
utilizada – Dynamo, e o tema programado – a Norma de Desempenho, conforme
disposto a seguir.
Em relação ao Dynamo, o fato de que este está vinculado a uma plataforma BIM
permite realizar rotinas manipulando diversas informações do modelo, porém, este
vínculo também compromete em parte a interoperabilidade de seu código de
programação com outras ferramentas de VPL, o que representa uma limitação nas
próprias extensões de programação.
Contudo, isto pode ser mitigado por componentes híbridos – que permitem que
códigos como Python e o DesignScript sejam transportados para outros softwares e,
portanto, as ferramentas desenvolvidas podem ser funcionais em múltiplas
plataformas. Um exemplo da ocorrência disto foram os pacotes Ladybug, que
originalmente foram desenvolvidos para Grasshopper, mas recentemente vêm sendo
integrados no Dynamo, devido ao fato de que seus componentes foram programados
em Python.
Outra limitação importante é de que a extensão Dynamo ainda está sendo refinada,
com frequentes atualizações. Um dos principais problemas é a lentidão e falta de
157
otimização de algumas das funcionalidades, o que desencoraja seu uso quando há
uma grande quantidade de elementos a serem processados e muitas operações
sequenciais envolvendo elementos BIM. No presente trabalho, isto foi mitigado pela
organização das rotinas em funcionalidades separadas – a exemplo do plug-in de
desempenho lumínico que, primeiro gera o grid a ser analisado, e depois preenche o
mesmo com cores. Por outra perspectiva, por vezes os usuários desenvolvedores de
pacotes customizados preocupam-se em gerar múltiplos outputs a partir de um único
input, o que pode contribuir para tornar o processamento de uma rotina mais lento,
uma vez que muitos dos outputs gerados não são utilizados efetivamente nas rotinas.
Isto leva à importância de criar custom nodes com finalidades bem definidas, em
detrimento de um node que faz múltiplas tarefas, visando a otimização das
ferramentas.
Reconhece-se que esta situação pode ser melhorada com o avanço das extensões,
contudo, é importante, como usuário das mesmas, apontar e discutir suas
fragilidades para que suas eventuais melhorias possam ser percebidas. No
desenvolvimento dos plug-ins do presente trabalho foi utilizado o Dynamo na versão
1.3.2.2480, e na data de término deste estudo foi lançada a versão 2.0, que,
possivelmente, resolveu alguns dos entraves e limitações, e trouxe novas funções.
A discussão da evolução das ferramentas também pode se estender para o Dyno
Browser, que, de forma similar, constantemente recebe novas funcionalidades e
melhorias. Conclui-se que é necessário respeitar o tempo para amadurecimento dos
softwares, e isso não significa que não possam ser experimentados no estado em que
se encontram.
Em relação à Norma de Desempenho, o trabalho mostrou que a programação em
softwares BIM possibilita integrações com a mesma, por meio da verificação de
requisitos, sobretudo no gerenciamento de informações de sistemas construtivos e no
atendimento dos níveis de desempenho.
Conforme destacado ao final do Capítulo 4, o preenchimento de parâmetros apenas
para fins de organização de informações não é suficiente para justificar o uso de BIM
para integrar o atendimento ao desempenho. É necessário utilizar BIM para avaliar,
verificar e simular situações de projeto, utilizando a abundância de informação para
efetivamente tomar decisões e não apenas como um banco de dados estático. Isto foi
apresentado por meio da demonstração dos plug-ins, que efetivamente utilizam os
parâmetros de desempenho em verificações e simulações.
Outro ponto a ser considerado é que não se pode esperar que o software realize todas
as atividades automaticamente, e sim utilizá-lo para direcionar as escolhas, que ainda
necessitam ser confirmadas pelo projetista.
158
Por fim, como ressaltado ao início deste capítulo, programar ferramentas
direcionadas possibilita a análise profunda das variáveis envolvidas, e assim,
verificam-se possíveis arbitrariedades na definição dos requisitos da Norma de
Desempenho, como margens de valores de desempenho. Analisa-se a real
efetividade de alguns dos requisitos da norma nas situações reais, e se estes
realmente são representativos no ambiente de projeto.
Um exemplo disto são os requisitos de desempenho lumínico contando apenas com
iluminação natural, explicitados neste trabalho pelo desenvolvimento do plug-in
para cálculo de iluminâncias internas. A norma define parâmetros como horários
específicos, nebulosidade, e uma análise no centro dos ambientes, questiona-se se
suas particularidades remetem à uma realidade representativa e influenciam
efetivamente na qualidade do desempenho lumínico – por meio da garantia de
ambientes bem iluminados quando, por exemplo, se tem ambientes com formas
irregulares, onde o centro do ambiente não é definido da mesma maneira.
Assim, conclui-se que o processo de programação das ferramentas permite também a
reflexão acerca da efetividade de documentos de referência como normas, e sua
aplicação nos projetos – que deve ser voltada a atender de forma eficaz a qualidade
de uma edificação em operação, e não apenas para cumprir com os valores de uma
faixa arbitrária de níveis de desempenho.
8.4 Trabalhos futuros e recomendações
Em pesquisas futuras, pretende-se continuar utilizando a abordagem da
programação para solução de problemas, sendo desenvolvidas outras ferramentas.
Os plug-ins desenvolvidos nesta pesquisa poderão ser calibrados conforme sugestões
da avaliação, e os resultados da pesquisa submetidos em congressos e periódicos. As
rotinas desenvolvidas poderão ser eventualmente compartilhadas nas comunidades
online para disseminar o conhecimento adquirido e técnicas empregadas.
Por fim, pretende-se intensificar o uso de TPL, notadamente Python, de modo a
acessar informações de bibliotecas de softwares além do Revit, como por exemplo, o
Navisworks. Isto permitirá ampliar o gerenciamento da informação para, em estudos
futuros, abranger novas dimensões do BIM, bem como para verificar oportunidades
de criação de pontes de interoperabilidade entre softwares.
Para pesquisadores e profissionais programadores, recomenda-se construir
ferramentas versáteis, com potencial para diferentes projetos e enfoque em soluções
que se adaptem a múltiplos cenários, em detrimento de soluções específicas para
uma única edificação. Recomenda-se também a adaptação constante às novidades
159
tanto na programação – onde muitos dos softwares e extensões utilizadas na
pesquisa são atualizados frequentemente; como no contexto do BIM em geral – por
trabalhos acadêmicos e atenção à novas regulamentações que padronizem e
direcionem o uso da informação nos projetos.
160
REFERÊNCIAS BIBLIOGRÁFICAS
ABNT. NBR 15215-3: Iluminação natural – Parte 3 : Procedimento de cálculo para a
determinação da iluminação natural em ambientes internos. Rio de Janeiro,
Brasil, 2004.
ABNT. NBR ISO 12006-2: Construção de edificação — Organização de informação da
construção - Parte 2: Estrutura para classificação de informação. Rio de Janeiro,
Brasil, 2010.
ABNT. NBR 15965-1: Sistema de classificação da informação da construção - Parte 1:
Terminologia e estrutura. Rio de Janeiro, Brasil, 2011.
ABNT. NBR 15575-1: Edificações Habitacionais — Desempenho Parte 1: Requisitos
gerais. Rio de Janeiro, Brasil, 2013a.
ABNT. NBR 15575-2: Edificações habitacionais — Desempenho Parte 2: Requisitos
para os sistemas estruturais. Rio de Janeiro, Brasil, 2013b.
ABNT. NBR 15575-3: Edificações habitacionais — Desempenho Parte 3: Requisitos
para os sistemas de pisos. Rio de Janeiro, Brasil, 2013c.
ABNT. NBR 15575-4: Edificações habitacionais — Desempenho Parte 4: Sistemas de
vedações verticais internas e externas - SVVIE. Rio de Janeiro, Brasil, 2013d.
ABNT. NBR 15575-5: Edificações habitacionais — Desempenho Parte 5 : Requisitos
para sistemas de coberturas. Rio de Janeiro, Brasil, 2013e.
ABNT. NBR 15575-6: Edificações Habitacionais — Desempenho Parte 6 : Requisitos
para os sistemas hidrossanitários. Rio de Janeiro, Brasil, 2013f.
ADVENSER. BIM Modeling Services, Architectural, Structural, MEP BIM, Steel
Detailing. 2018. Disponível em: <https://www.advenser.ae/bim-services/>.
Acesso em: 21 maio. 2018.
AISH, Robert. Extensible Computational Design Tools for Exploratory Architecture.
In: KOLAREVIC, Branko (Ed.). Architecture in the digital age: design and
manufacturing. New York: Taylor & Francis Group, p. 338–347, 2003.
AISH, Robert; MARSH, Andrew. An Integrated Approach to Algorithmic Design
and Environmental Analysis. Proceedings of the 2011 Symposium on
Simulation for Architecture and Urban Design, p. 149–155, 2011.
AISH, Robert et al. Progress towards Multi-Criteria Design Optimisation using
DesignScript with SMART Form, Robot Structural. In: Proceedings ACADIA
2012: Synthetic Digital Ecologies, San Francisco, 2012.
AISH, Robert. First Build Your Tools. Inside Smartgeometry: Expanding the
Architectural Possibilities of Computational Design, p. 36–49, 2013a.
AISH, Robert. DesignScript : a learning environment for Design Computation. In:
Design Modelling Symposium, Berlim, 2013b.
AISH, Robert; MENDOZA, Emmanuel. DesignScript: a domain specific language for
architectural computing. Proceedings of the International Workshop on
Domain-Specific Modeling - DSM 2016, p. 15–21, 2016.
ARJUNAN, A. et al. Development of a 3D finite element acoustic model to predict
161
the sound reduction index of stud based double-leaf walls. Journal of Sound
and Vibration, v. 333, n. 23, p. 6140–6155, 2014.
AUTODESK. Ecotect Analysis Discontinuation FAQ. 2016. Disponível em:
<https://knowledge.autodesk.com/support/ecotect-analysis/learn-
explore/caas/sfdcarticles/sfdcarticles/Ecotect-Analysis-Discontinuation-
FAQ.html>. Acesso em: 1 set. 2017.
AUTODESK. Navisworks - Project Review Software. 2017a. Disponível em:
<http://www.autodesk.com/products/navisworks/overview>. Acesso em: 23 jul.
2017.
AUTODESK. Dynamo Player. 2017b. Disponível em:
<https://knowledge.autodesk.com/support/revit-products/learn-
explore/caas/CloudHelp/cloudhelp/2017/ENU/Revit-AddIns/files/GUID-
BFCE20D2-86D4-4591-8CF3-5405D26DB825-htm.html>. Acesso em: 1 set. 2017.
AUTODESK. Autodesk App Store. 2017c. Disponível em:
<https://apps.autodesk.com/RVT/en/Home/Index>. Acesso em: 23 jul. 2017.
BENTLEY. Generative Components. 2018. Disponível em:
<https://www.bentley.com/en/products/product-line/modeling-and-
visualization-software/generativecomponents>. Acesso em: 7 mar. 2018.
BIBLUS-NET. Cos’è il BIM? 2018. Disponível em: <http://biblus.acca.it/focus/bim-
building-information-modeling/>. Acesso em: 21 maio. 2018.
BIMETICA. BIM Marketing for Manufacturers. 2018. Disponível em:
<http://manufacturers.bimetica.com/wp-content/uploads/2014/07/img-
auditoria-3.png>.
BIMFORUM. Level of Development Specification 2017 Part I. 2017. Disponível em: <
http://bimforum.org/lod/>.
BIOTTO, Clarissa Notariano; FORMOSO, Carlos Torres; ISATTO, Eduardo Luis. Uso
de modelagem 4D e Building Information Modeling na gestão de sistemas de
produção em empreendimentos de construção. Ambiente Construído, v. 15, n.
2, p. 79–96, 2015.
BRASIL. Decreto de 5 de junho de 2017. Institui o Comitê Estratégico de
Implementação do Building Information Modelling. Diário Oficial, Brasília, DF,
5 jun. 2017.
BRASIL. Decreto nº 9.377, de 17 de maio de 2018. Institui a Estratégia Nacional de
Disseminação do Building Information Modelling. Diário Oficial, Brasília, DF,
17 mai. 2018.
BRIGITTE, Giovanna Tomczinski Novellini; RUSCHEL, Regina Coeli. Modelo de
informação da construção para o projeto baseado em desempenho:
caracterização e processo. Ambiente Construído, v. 16, n. 4, p. 9–26, 2016.
BSEN 12354-1. Building acoustics - Estimation of acoustic performance of buildings
from the performance of elements. Airborne sound insulation between rooms.
BSI Standards Publication, 2000.
BSEN ISO 10140. Acoustics – Laboratory Measurement of Sound Insulation of
162
Building Elements, Part 2: Measurement of Airborne Sound Insulation. BSI
Standards Publication, 2010.
BSEN ISO 717-1. Acoustics: Rating of Sound Insulation in Buildings and of Building
Elements, Part 1: Airborne Sound Insulation. BSI Standards Publication, 2006.
BUILDINGSMART. International home of openBIM. 2017. Disponível em:
<http://www.buildingsmart-tech.org/>. Acesso em: 23 jul. 2017.
CBIC. Desempenho De Edificações Habitacionais: Guia Orientativo Para
Atendimento à Norma ABNT NBR 15575/2013, Fortaleza, 2013.
CBIC. Implantação do BIM para construtoras e incorporadoras: Parte 1 -
Fundamentos BIM. Brasília, 2016.
CELANI, Gabriela et al. The Future of the Architects’s Employment: To Which Extent
Can Architectural Design be Computerised? In: CELANI, Gabriela; SPERLING,
David Moreno; FRANCO, Juarez Moara Santos (Eds.). Computer-Aided
Architectural Design. The Next City - New Technologies and the Future of the
Built Environment. 16th International Conference, CAAD Futures 2015. São
Paulo, Brasil, p. 195-212, 2015.
COSTA, Carolina Helena de Almeida; ILHA, Marina Sangoi de Oliveira.
Componentes BIM de sistemas prediais hidráulicos e sanitários baseados em
critérios de desempenho. Ambiente Construído, v. 17, n. 2, p. 157–174, 2017.
COTTA, Ana Cláudia; ANDERY, Paulo Roberto Pereira. As alterações no processo
de projeto das empresas construtoras e incorporadoras devido à NBR 15575 –
Norma de Desempenho. Ambiente Construído, v. 18, n. 1, p. 133–152, 2018.
DATA-SHAPES. Data|Shapes. 2017. Disponível em: <https://data-shapes.net/>.
Acesso em: 1 set. 2017.
DAVOODI, Anahita. Lighting Simulation for a more value-driven building design
process. 2016. Department of Civil Engineering and Lighting Science, Jönköping
University, 2016.
DAYSIM. Daysim - Advanced Daylight Simulation Software. 2017. Disponível em:
<http://daysim.ning.com/>. Acesso em: 1 set. 2017.
DRESCH, Aline; LACERDA, Daniel Pacheco; ANTUNES JR., José Antonio Valle.
Design Science Research : A Method for Science and Technology Advancement.
Springer International Publishing, 2015.
DYNAMO. Dynamo BIM: Open source graphical programming for design. 2018a.
Disponível em: <http://dynamobim.org/>. Acesso em: 23 jul. 2017.
DYNAMO. DynamoBIM Forum. 2018b. Disponível em:
<https://forum.dynamobim.com/>. Acesso em: 2 ago. 2017.
DYNAMO. About | The Dynamo Primer. 2018c. Disponível em:
<http://dynamoprimer.com/en/>. Acesso em: 6 jun. 2018.
DYNAMONODES. All about Dynamo Nodes. 2017. Disponível em:
<https://dynamonodes.com/>. Acesso em: 2 ago. 2017.
DYNAMONODES. DynaWorks - Dynamo Nodes. 2018. Disponível em:
<https://dynamonodes.com/category/dynaworks/>. Acesso em: 6 jun. 2018.
163
EASTMAN, Charles M. Recent developments in representation in the science of
design. Pittsburgh, 1981.
EASTMAN, Chuck et al. BIM Handbook. Hoboken, New Jersey: John Wiley & Sons,
Inc., 2008.
ENERGYPLUS. Weather Data - Energy Plus. 2017. Disponível em:
<https://energyplus.net/weather>. Acesso em: 23 jul. 2017.
FELIPPE, Alexandre Reis et al. Modelagem paramétrica para simulação do
desempenho da iluminação natural e termo-energético da edificação. In:
SIGRADI 2015, Florianopolis, Brasil, 2015.
FERREIRA, Rita Cristina; SANTOS, Eduardo Toledo. Características Da
Representação 2D E Suas Limitações Na Etapa De Compatibilização Espacial
Do Projeto. Gestão & Tecnologia de Projetos, v. 2, n. 2, p. 36–52, 2007.
FERREIRA, Bruno; LEITÃO, Antônio. Generative Design for Building Information
Modeling. In: Proceedings Of The 33RD ECAADE Conference, Vienna, Austria,
2015.
FOOD4RHINO. Food4Rhino. 2018. Disponível em: <http://www.food4rhino.com/>.
Acesso em: 7 mar. 2018.
GARBER, Richard. Optimisation Stories: The Impact of Building Information
Modeling on Contemporary Design Practice. In: GARBER, Richard (Ed.).
Closing the Gap: Information Models in Contemporary Design Practice. John
Wiley & Sons, p. 6–13, 2009.
GARBINI, Marcele Ariane Lopes; BRANDÃO, Douglas Queiroz. Proposta de Modelo
para Implantação de Processo de Projeto Utilizando o Conceito BIM em
Escritórios de Arquitetura. Gestão e Tecnologia de Projetos, v. 9, n. 1, p. 7–24,
2014.
GAUCHAT, Urs. The $300,000/Year Architect. In: GARBER, Richard (Ed.). Closing
the Gap: Information Models in Contemporary Design Practice. John Wiley &
Sons, p. 32–37, 2009.
GERRISH, Tristan et al. BIM application to building energy performance
visualisation and management: Challenges and potential. Energy and
Buildings, v. 144, p. 218–228, 2017.
GITHUB. GitHub - DynamoDS/Dynamo. 2018a. Disponível em:
<https://github.com/DynamoDS/Dynamo>. Acesso em: 6 jun. 2018.
GITHUB. GitHub - Dynosaur on Ladybug Tools. 2018b. Disponível em:
<https://github.com/ladybug-tools/dynosaur>. Acesso em: 6 jun. 2018.
GOES, Renata Heloisa de Tonissi e Buschinelli de. Compatibilização de projetos com
a utilização de ferramentas BIM. 2011. 143f. Dissertação (Mestrado em
Habitação). IPT - Instituto de Pesquisas Tecnológicas do Estado de São Paulo,
São Paulo, 2011.
GRAPHISOFT. Archicad 21. 2017. Disponível em:
<http://www.graphisoft.com/br/archicad/index.html>. Acesso em: 1 set. 2017.
GRASSHOPPER. Grasshopper - Algorithmic Modeling for Rhino. 2018. Disponível
164
em: <http://www.grasshopper3d.com/>. Acesso em: 6 jun. 2018.
HENSEN, Jan L. M.; LAMBERTS, Roberto. Building performance simulation for
design and operation. Routledge, 2011.
HEVNER, Alan R. et al. Design Science in Information Systems Research. MIS
Quarterly, v. 28, n. 1, p. 75–105, 2004.
HOLMSTRÖM, Jan; KETOKIVI, Mikko; HAMERI, Ari-Pekka. Bridging Practice and
Theory: A Design Science Approach. Decision Sciences,, v. 40, n. 1, p. 65–87,
2009.
HOLZER, Dominik. BIM and Parametric Design in Academia and Practice: The
Changing Context of Knowledge Acquisition and Application in the Digital
Age. International Journal of Architectural Computing, v. 13, n. 1, p. 65–82,
2015.
HYDRA. Hydra - Sharing made easy! 2018. Disponível em:
<http://hydrashare.github.io/hydra/>. Acesso em: 7 mar. 2018.
JALAEI, Farzad; JRADE, Ahmad. An Automated BIM Model to Conceptually
Design, Analyze, Simulate, and Assess Sustainable Building Projects. Journal of
Construction Engineering, v. 2014, p. 1–21, 2014.
JANSSEN, Patrick. Parametric BIM Workflows. In: Proceedings of the 20th
International Conference on Computer-Aided Architectural Design Research in
Asia - CAADRIA 2015, Daegu, Republic of Korea, 2015.
KASANEN, Aero; LUKKA, Kari; SIITONEN, Arto. The Constructive Approach in
Management Accounting Research. Journal of Management Accounting
Research, v. 5, p. 243–264, 1993.
KENSEK, Karen. BIM Guidelines Inform Facilities Management Databases: A Case
Study over Time. Buildings, v. 5, n. 3, p. 899–916, 2015.
KEOUGH, Ian; HAUCK, Anthony. From Pencils to Partners: The Next Role of
Computation in Building Design. In: GARBER, Richard (Ed.). Workflows:
Expanding Architecture’s Territory in the Design and Delivery of Buildings, p.
74–81, 2017.
KHAJA, A. M.; SEO, J. D.; MCARTHUR, J. J. Optimizing BIM metadata manipulation
using parametric tools. Procedia Engineering, v. 145, n. 2016, p. 259–266, 2016.
KHAN, Mohd Ehmer. Different Approaches to Black Box Testing Technique for
Finding Errors. International Journal of Software Engineering & Applictions, v.
2, n. 4, p. 31–40, 2011.
KIM, Myung Jun; KIM, Ha Geun. Field measurements of façade sound insulation in
residential buildings with balcony windows. Building and Environment, v. 42,
n. 2, p. 1026–1035, 2007.
KIRKEGAARD, Poul Henning; KAMARI, Aliakbar. Building Information Modeling
(BIM) for Indoor Environmental Performance AnalysisCivil and Architectural
Engineering - Technical report CAE-TR-3. Department of Engineering – Civil
and Architectural Engineering, Aarhus University, Aarhus, Denmark, 2017.
KORMAN, T. M.; SIMONIAN, L.; SPEIDEL, E. How building information modeling
165
has changed the MEP coordination process. Challenges, Opportunities and
Solutions in Structural Engineering and Construction, Taylor & Francis,
London, p. 959–964, 2010.
LACERDA, Daniel Pacheco et al. Design Science Research : método de pesquisa para
a engenharia de produção. Gestão & Produção, v. 20, n. 4, p. 741–761, 2013.
LADYBUG. Ladybug Tools. 2018. Disponível em: <http://www.ladybug.tools/>.
Acesso em: 5 maio. 2017.
LEITÃO, António; SANTOS, Luís; LOPES, José. Programming Languages for
Generative Design: A Comparative Study. International Journal of Architectural
Computing, v. 10, n. 1, p. 139–162, 2012.
LI, Jian et al. A project-based quantification of BIM benefits. International Journal of
Advanced Robotic Systems, v. 11, n. 1, p. 1–13, 2014.
LI, Jinmin. Integrating Building Information Modelling (BIM), Cost Estimating and
Scheduling for Buildings Construction at the Conceptual Design Stage. 2016.
176f. Tese (Master of Applied Science in Civil Engineering). Ottawa-Carleton
Institute for Civil Engineering, Faculty of Engineering, University of Ottawa,
2016.
LUKKA, Kari. The Constructive Research Approach. In: OJALA, Lauri; HILMOLA,
Olli-Pekka (Eds.). Case Study Research in Logistics. Series B1. Turku School of
Economics and Business Administration, p. 83–101, 2003.
MACKEY, Chris; ROUDSARI, Mostapha Sadeghipour. The Tool(s) Versus The
Toolkit. Humanizing Digital Reality, p.93-101, 2017.
MARCH, Salvatore T.; SMITH, Gerald F. Design and natural science research on
information technology. Decision Support Systems 15, v. 15, n. 4, p. 251–266,
1995.
MATCHA, Heike; QUASTEN, Gero. A Parametric-Typological Tool: More Diversity
for Mass Produced Single Family Homes Through Parametrized Design and
Customized Mass Production. In: Computation: The New Realm of
Architectural Design: 27th eCAADe Conference Proceedings. Istanbul, Turkey,
p. 409-416, 2009.
NARDELLI, Eduardo Sampaio; OLIVEIRA, João Tales. BIM e Desempenho no
Programa Minha Casa Minha Vida ‐ PMCMV. In: XVII Conference of the
Iberoamerican Society of Digital Graphics - SIGraDi: Knowledge-based Design,
v. 1, n. 7, p. 312-316, 2013.
NEGENDAHL, Kristoffer. Building performance simulation in the early design
stage: An introduction to integrated dynamic models. Automation in
Construction, v. 54, p. 39–53, 2015.
NEMETSCHEK. Scia Structural Analysis and Open BIM with Autodesk Revit. 2018.
Disponível em: <https://www.scia.net/en/scia-engineer-structural-analysis-and-
open-bim-autodesk-revit>. Acesso em: 21 maio. 2018.
OTTCHEN, Cynthia. The Future of Information Modelling and the End of Theory:
Less is Limited, More is Different. In: GARBER, Richard (Ed.). Closing the Gap:
166
Information Models in Contemporary Design Practice. John Wiley & Sons, p.
22–27, 2009.
PAPAMICHAEL, K. et al. The Building Design Advisor. Proceedings of the ACADIA
1996 Conference, p. 1–17, 1996.
PAPAMICHAEL, Konstantinos. Application of information technologies in building
design decisions. Building Research & Information, v. 27, p. 20–34, 1998.
PAULUZZI. Biblioteca BIM Pauluzzi. 2018. Disponível em:
<http://pauluzzi.com.br/bim/>. Acesso em: 6 mar. 2018.
PITTMAN, Jon. Building Information Modeling: Current Challenges and Future
Directions. In: KOLAREVIC, Branko (Ed.). Architecture in the digital age:
design and manufacturing. New York: Taylor & Francis Group, p. 348–354,
2003.
PORTOBELLO. Especificador Virtual - Biblioteca BIM Portobello. 2018. Disponível
em: <http://especificadorvirtual.portobello.com.br/area_tecnica>. Acesso em: 13
mar. 2018.
PRORUBIM. Dyno Browser. 2017. Disponível em:
<http://prorubim.com/en/tools/dyno/>. Acesso em: 1 set. 2017.
PYTHON. Welcome to Python. 2018. Disponível em: <https://www.python.org/>.
Acesso em: 6 jun. 2018.
RADIANCE. Radiance – A Validated Lighting Simulation Tool. 2017. Disponível em:
<https://www.radiance-online.org/>. Acesso em: 23 jul. 2017.
RHINO3D. Rhino Features. 2018. Disponível em:
<https://www.rhino3d.com/6/features>. Acesso em: 6 jun. 2018.
ROCHA, Cecilia G. et al. Design Science Research in Lean Construction : Process and
Outcomes. In: Proceedings for the 20th Annual Conference of the International
Group for Lean Construction. San Diego, California, 2013.
ROUDSARI, Mostapha Sadeghipour et al. Ladybug: a Parametric Environmental
Plugin for Grasshopper To Help Designers Create an Environmentally-
Conscious Design. 13th Conference of International building Performance
Simulation Association, p. 3129–3135, 2013.
RUSCHEL, Regina Coeli et al. O Papel das Ferramentas BIM de Integração e
Compartilhamento no Processo de Projeto na Indústria da Construção Civil.
REEC-Revista Eletrônica de Engenharia Civil, v. 7, n. 3, p. 36–54, 2013.
SAINT-GOBAIN. Espaço Técnico - Cálculo de material e biblioteca BIM Placo. 2018.
Disponível em: <https://www.placo.com.br/espaco-tecnico-calculo-de-material-
e-biblioteca-bim-placo>. Acesso em: 13 mar. 2018.
SANHUDO, Luís Pedro Neves. BIM for Building Sustainability Assessment:
Development of a software tool for Rainwater Runoff mitigation. 2016. 193f.
Dissertação (Mestrado em Engenharia Civil). Faculdade de Engenharia -
Universidade do Porto, 2016.
SCHLUETER, Arno; THESSELING, Frank. Building information model based
energy/exergy performance assessment in early design stages. Automation in
167
Construction, v. 18, n. 2, p. 153–163, 2009.
SEGHIER, Taki Eddine et al. Building Envelope Thermal Performance Assessment
Using Visual Programming and BIM , based on ETTV requirement of Green
Mark and GreenRE. International Journal Of Built Environment And
Sustainability, v. 4, n. 3, p. 227–235, 2017.
SHELDEN, Dennis. Information Modelling as a Paradigm Shift. In: GARBER,
Richard (Ed.). Closing the Gap: Information Models in Contemporary Design
Practice. John Wiley & Sons, p. 80–83, 2009.
SHI, Xing; YANG, Wenjie. Performance-driven architectural design and optimization
technique from a perspective of architects. Automation in Construction, v. 32, p.
125–135, 2013.
SILVA, Flávio; ARANTES, Eduardo. Proposta de verificação automática dos
requisitos de projetos pelo uso de ferramentas de análise BIM aplicados a
Norma de Desempenho. In: XVI Encontro Nacional De Tecnologia Do
Ambiente Construído 2016. São Paulo, Brasil, 2016.
SILVA, Juliano Lima da et al. BIM Software Plug-ins: An Alternative to Optimize
Design Processes from the Perspective of Performance and Sustainability.
Journal of Civil Engineering and Architecture, v. 11, n. 3, p. 249–264, 2017a.
SILVA, Juliano Lima da et al. Compatibilização e Coordenação de Projetos: Estudo
de Caso de Implementação de BIM. In: Anais Do XI Mostra de Iniciação
Científica e Extensão Comunitária, X Mostra De Pesquisa De Pós-Graduação.
Faculdade Meridional IMED, Passo Fundo, Brasil, 2017b.
SILVA JÚNIOR, Mauro Augusto; MITIDIERI FILHO, Cláudio Vicente. Requisitos de
desempenho aplicados em projetos de arquitetura com o uso de BIM. Revista
Téchne, v. 24, n. 33, p. 43–47, 2015.
SIMON, Herbert A. The Sciences of the Artificial. Third Edit ed. Cambridge,
Massachussetts: MIT Press, 1996. Disponível em:
<http://linkinghub.elsevier.com/retrieve/pii/S0898122197829410>
SINGH, Manav Mahan; SAWHNEY, Anil; BORRMANN, André. Integrating rules of
modular coordination to improve model authoring in BIM. International
Journal of Construction Management, p. 1–17, 2017.
SOUZA, Jonas Leonardo Pessanha De; KERN, Andrea Parisi; TUTIKIAN, Bernardo
Fonseca. Análise quantiqualitativa da Norma de Desempenho (NBR No
15.575/2013) e principais desafios da implementação do nível superior em
edificação residencial de multipavimentos. Gestão & Tecnologia de Projetos, v.
13, n. 1, p. 127–144, 2018.
SOUZA, Roberta Vieira Gonçalves De. Iluminação Natural em Edificações: cálculo de
iluminâncias internas - desenvolvimento de ferramenta simplificada. 1997. 176f.
Dissertação (Mestrado em Engenharia Civil). Universidade Federal de Santa
Catarina, 1997.
STADEL, A. et al. Intelligent sustainable design: Integration of carbon accounting
and building information modeling. Journal of Professional Issues in
168
Engineering Education and Practice, v. 137, n. 2, p. 51–54, 2011.
SUCCAR, Bilal. Building information modelling framework: A research and delivery
foundation for industry stakeholders. Automation in Construction, v. 18, n. 3, p.
357–375, 2009.
SUCCAR, Bilal; SHER, Willy; WILLIAMS, Anthony. An integrated approach to BIM
competency assessment, acquisition and application. Automation in
Construction, v. 35, n. p. 174–189, 2013.
SUCCAR, Bilal et al. The Five Components of BIM Performance Measurement.
Building Design, v. 19, p. 287–300, 2014.
TAKAHASHI, Vanessa Fátima de Medeiros. Desempenho acústico de edificações:
ferramenta computacional para avaliação. 2016. 168f. Tese (Doutorado em
Engenharia Civil). Universidade Estadual de Campinas, 2016.
TZORTZOPOULOS, P. Contribuições para o desenvolvimento de um modelo do
processo de projeto de edificações em empresas construtoras incorporadoras de
pequeno porte. 1999. 164f. Dissertação (Mestrado em Engenharia Civil).
Universidade Federal do Rio Grande do Sul, 1999.
VAISHNAVI, Vijay K.; KUECHLER, William. Design Science Research Methods and
Patterns: Innovating Information and Communication Technology. Second
Edition. CRC Press, 2007.
VAN AKEN, J. E. Management research on the basis of the design paradigm: The
quest for field-tested and grounded technological rules. Journal of Management
Studies, v. 41, n. 2, p. 219–246, 2004.
VECTORWORKS. Marionette Training. 2018. Disponível em:
<http://www.vectorworks.net/training/marionette>. Acesso em: 7 mar. 2018.
VIOLA, Anthony; ROUDSARI, Mostapha Sadeghipour. An Innovative Workflow For
Bridging The Gap Between Design And Environmental Analysis. In: 13th
Conference of International Building Performance Simulation Association.
Chambery, França, 2013.
WHITEHEAD, Hugh. Laws of Form New York: Taylor & Francis, 2003. p. 116-148.
In: KOLAREVIC, Branko (Ed.). Architecture in the digital age: design and
manufacturing. New York: Taylor & Francis Group, p. 116–148, 2003.
WU, Wei. Integrating Building Information Modeling and Green Building
Certification: The BIM-LEED Application Model Development. 2010. 181f. Tese
(Ph.D. ).University of Florida, 2010.
WU, Chengde; CLAYTON, Mark J. BIM-Based Acoustic Simulation Framework. In:
CIB W78 International Conference. Beijing, China, 2013.
ZHANG, Sijie et al. Building Information Modeling (BIM) and Safety: Automatic
Safety Checking of Construction Models and Schedules. Automation in
Construction, v. 29, 2013.
ZHANG, Cheng; CHEN, Shuixiang; KANG, Byung-gyoo. LEED embedded BIM for
Construction Sustainability Analysis. International Journal of Science Research
and Technology, v. 1, n. 1, p. 95–101, 2015.
169
APÊNDICE A
Artigo do survey para delimitação do tema
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
APÊNDICE B
187
188
189
190
191
192
193
194
195
196
APÊNDICE C
1. Plug-in de desempenho acústico – Calcular Rw
197
198
199
200
201
202
2. Plug-in de desempenho acústico – Verificar Desempenho
203
204
205
206
207
208
209
3. Plug-in de desempenho acústico – Reset
210
4. Plug-in de desempenho acústico – Ajuda
211
212
213
5. Plug-in de desempenho lumínico – Gerar Grid
214
215
216
217
218
219
220
6. Plug-in de desempenho lumínico – Análise LUX
221
222
223
224
225
226
227
228
229
230
7. Plug-in de desempenho lumínico – Análise FLD
OBS: mesma
programação do
item 6, apenas com
valores da escala e
alguns nomes de
parâmetros
modificados
231
8. Plug-in de desempenho lumínico – Reset
232
9. Plug-in de desempenho lumínico – Ajuda
233
234
