Projeto e Desenvolvimento: 2º Ciclo

Esta subseção apresenta o Projeto e Desenvolvimento do 2º Ciclo e descreve as soluções empregadas nas Camadas de Serviço e Interface do protótipo sequencialmente. Assim como no 1º Ciclo, destaca-se que os procedimentos foram desenvolvidos de modo iterativo, embora estejam documentados dessa forma.

4.2.3.1 Camada de Serviço

O Projeto e o Desenvolvimento da Camada de Serviço do 2º Ciclo foram estruturados no intuito de ajustar o Modelo de Registro BIM para monitoramento de desempenho, extrair informações do ThingSpeak e/ou do banco de dados MySQL, e inserir estas informações no Modelo de Registro BIM em um ambiente nativo: o Autodesk Revit 2017.

Projeto

Inicialmente, determinou-se o isolamento da Edificação Anexo 01 do Modelo de Registro BIM – a qual o LAMPA está lotado – para adequações visando as atividades de monitoramento de desempenho. As adequações foram relativas aos objetos BIM do sistema de iluminação (Luminárias e Canaletas) e do laboratório de pesquisa (Room 2D e Room 3D33), correspondentes os objetos reais sob monitoramento. Nesse sentido, demandou-se: (i) a revisão das propriedades existentes e terminologias dos objetos BIM indicados; (ii) a criação de propriedades COBie armazenadas em tipo e instância para inserir registros de ativos; (iii) a criação de propriedades compartilhadas armazenadas em instância para inserir informações de monitoramento em tempo real; e (iv) a criação de vistas 3D, templates de vista e tabelas dedicadas para monitoramento de desempenho. Em termos de classificação, consideraram-se os objetos BIM que constituem o sistema de iluminação como ativos e aqueles que constituem os ambientes como espaços.

Além destas demandas, constatou-se a necessidade de modelar e/ou aprimorar as famílias de objetos BIM lotados na área do laboratório de pesquisa, como no caso das Canaletas e do Room 3D, este último representando o ambiente do laboratório tridimensionalmente.

Em seguida, definiu-se o método a ser aplicado para a integração das informações do ambiente físico com o Modelo de Registro em um ambiente BIM nativo, o Autodesk Revit 2017. A integração pode ser realizada com auxílio ou não de add-in, sendo em ambos os casos, requerido acesso à Revit API.

O método de integração com auxílio de add-in demanda amplo conhecimento nas sintaxes e semânticas de programação de linguagens textuais e não gráfica suportadas nativamente na ferramenta BIM, como VB.NET, C# e C++/CLI. Ademais, o desenvolvimento de software para integração nesse contexto requer a aquisição do Software Development Kit (SDK) do Autodesk Revit (AUTODESK, 2017). Além de permitir o desenvolvimento de software aplicados em diversas finalidades por meio da Revit API, o add- in criado pode apresentar funcionalidades manipulação e/ou sobreposição gráfica de objetos BIM, integração das informações de modo automatizado, com ou sem ação do usuário;

33 _{No Autodesk Revit não há funcionalidade de visualização de objetos Room em vistas 3D, ainda que haja a}

propriedade volume. Para atender a esta limitação, foram geradas geometrias tridimensionais de Room modelados e representados pela categoria de objetos Generic Models. Por esta razão discrimina-se os objetos em

interoperabilidade do Modelo BIM com soluções externas – como bancos de dados e serviços da Web; e configuração de interfaces do usuário para integrar diversos tipos de feedback e recursos secundários de visualização.

Já o método de integração sem auxílio de add-in pode ser aplicado de duas formas: através de ambientes de linguagem de programação visual ou através de add-ons que adicionem à ferramenta BIM intérpretes de linguagens de programação não nativas. No domínio do Autodesk Revit 2017, a primeira forma conduz ao Dynamo - um middleware BIM proprietário, disponível nativamente na interface da ferramenta BIM desde a versão 2016. O Dynamo é um ambiente de VPL em código aberto, que utiliza a Revit API. Nesse âmbito, é possível criar e desenvolver software, nas linguagens DesignScript e Python, a partir de elementos gráficos como nodes, que comunicam-se por meio de conectores. As conexões entre esses elementos resultam em rotinas (scripts) que podem ser aplicadas com diversas finalidades e ampliam os recursos da ferramenta BIM mencionada (KENSEK, 2015b; DYNAMO PRIMER, 2017). As aplicações e a ampliação de recursos são semelhantes ao primeiro método, com exceção das funcionalidades de configuração de interfaces do usuário. Para agregar UIs às rotinas do Dynamo, faz-se necessário o uso de ferramentas adicionais, como o Dynamo Player e/ou o Dyno Browser/Studio. Em relação à segunda forma, tem-se o add-on RevitPythonShell, que adiciona à ferramenta BIM um intérprete da linguagem de programação Python. Logo, é possível, instalando o SDK do Autodesk Revit, acessar a Revit API e criar software aplicados em diversas finalidades, além de ampliar recursos, como já apontado nos demais caminhos.

Destaca-se que independente do método e vertente empregados, este cenário visou a contextualização semântica e a visualização 3D de informações, sendo dedicado ao usuário com expertise no uso da ferramenta e olhar técnico em relação às atividades de monitoramento de desempenho. Entre as opções apresentadas, definiu-se a escolha do método que dispensa criação de add-in, com uso do Dynamo, para viabilizar a integração necessária. Essa escolha objetivou assegurar o cenário estabelecido na pesquisa, referente a demandar-se acesso direto para manutenção recorrente do Modelo de Registro BIM. Levou-se em consideração a facilidade de compreensão de ambientes de VPL para o desenvolvimento de software, devido a suas características gráficas e menor requisição de expertise em linguagens de programação. Para ratificar a integração BIM-IoT, determinou-se a verificação no próprio Dynamo, por meio de nodes de visualização.

Desenvolvimento

Como definido em projeto, as adequações do Modelo de Registro BIM contemplaram os objetos BIM pertencentes às famílias de Luminárias e Canaletas, que constituem o sistema de iluminação, e Room 2D e Room 3D, relacionados ao laboratório de pesquisa.

Inicialmente, foram modelados os objetos Room 3D e Canaletas do sistema de iluminação do LAMPA. Em seguida, foi realizada a revisão de dados geométricos (ex. posicionamento e dimensões das luminárias e canaletas instaladas) e não geométricos (ex. numeração atual das salas do 1º Pavimento) dos objetos existentes. Fazendo-se uso do add-on COBie Extension for Revit, foram criadas as propriedades COBie armazenadas em tipo e instância nos ativos (componentes do sistema de iluminação) e nos espaços (Rooms 2D e 3D) do modelo BIM.

No caso dos ativos, foram inseridas nas propriedades COBie padrão informações de controle (relativas ao responsável pela criação e à data de criação das propriedades), bem como informações associadas aos objetos BIM, como nomenclatura do ativo, sua descrição e espaço no qual se localiza. Estas informações associadas aos objetos BIM foram espelhadas de suas propriedades nativas. Devido à falta de disponibilidade de informações relacionadas aos registros de ativos (ex. data de instalação, garantia, código de barras) para inserção manual, parte das propriedades criadas não foram preenchidas.

No caso dos espaços, foram inseridas informações de controle e informações associadas aos objetos BIM, como nomenclatura, categoria, descrição e áreas do espaço, mediante o mesmo procedimento de espelhamento de suas propriedades nativas mencionado no caso dos ativos. Particularmente, em relação às propriedades de categoria (ex. COBie.Space.Category), a inserção de informações foi realizada através de um add-on que atua junto com o COBie Extension for Revit: o Autodesk Classification Manager for Revit. Este add-on permite acesso a diversos sistemas de classificação (ex. MasterFormat, UniFormat, OmniClass, Uniclass), dentre os quais foi empregado o OmniClass.

Logo, se iniciou a criação das propriedades compartilhadas para inserir informações de monitoramento em tempo real, diretamente associadas aos componentes de exibição da estratégia de eco-feedback. Essas propriedades foram configuradas contemplando nomenclatura, disciplina e tipo; e agrupadas por finalidade de monitoramento de desempenho: consumo de energia, grupo o qual foram atribuídas 16 propriedades padrão, e dados ambientais, grupo o qual foram atribuídas 5 propriedades padrão (Quadro 20).

Quadro 20 - Configurações das Propriedades Compartilhadas de Monitoramento

GRUPO NOMENCLATURA PADRÃO DISCIPLINA TIPO ARMAZENAMENTO

Consumo de Energia

Energy Consumption Monitoring

Propriedade Comum a Todas as Disciplinas Boolean Instância Status Text Report Text ReportDescription Text TimeStamp Text WattsRealTime Number WattsHLastHour Number WattsHLastDay Number WattsHLastMonth Number WattsHLastYear Number WorkingHours Text CostLastMonth Number CO2eLastMonth Number CostLastYear Number CO2eLastYear Number RealTimeMonitoringChart URL Dados Ambientais Environmental Monitoring Propriedade Comum a Todas as Disciplinas Boolean Instância TimeStamp Text HumidityRealTime Number TemperatureRealTime Number RealTimeMonitoringChart URL Fonte: A autora.

A configuração de tipo de propriedade foi fixada de acordo com a estrutura em JSON, adotada no ThingSpeak, e com as configurações atribuídas às estruturas das tabelas criadas no ecmlampa, adotada no banco de dados MySQL. Devido à diversidade de propriedades criadas, somente aquelas cujos tipos de informação eram Boolean ou em formato URL não foram consideradas para atualização periódica e/ou inserção de informações externas ao ambiente BIM nativo. Finalmente, é relevante destacar que o armazenamento, ou forma de atribuição, das propriedades nos objetos BIM, assim como a nomenclatura final adotada, variou de acordo com a categoria de famílias dos objetos BIM monitorados e com a estratégia de exibição das informações.

Após a atualização dos objetos BIM e suas propriedades, se iniciou a criação das vistas 2D e 3D dedicadas ao monitoramento de desempenho, sendo estas concebidas de acordo com os níveis de granularidade de visualização das informações. Na desagregação empregada, foi concebido um template de vista 2D para visualização e acesso às propriedades do objeto Room 2D, contextualizado no pavimento o qual o LAMPA está lotado (Figura 58). Por sua vez, atribuiu-se às duas vistas 3D visibilidades gráficas dedicadas à visualização e acesso às

propriedades de objetos BIM do Sistema de Iluminação (Canaletas e Luminárias) e do Room 3D, respectivamente, contextualizados no ambiente e no pavimento (Figura 59).

Figura 58 - Template de Vista 2D Dedicado a Monitoramento de Desempenho

Fonte: A autora.

Figura 59 - Vistas 3D de Luminárias e Canaletas (Esquerda) e Rooms 3D (Direita) Dedicadas a Monitoramento de Desempenho

Para todas as vistas criadas, foram concebidas sobreposições gráficas dinâmicas, baseadas nas informações a serem inseridas através do Dynamo. Ademais, foram criadas e organizadas tabelas de monitoramento de desempenho, agregando propriedades COBie e de monitoramento para exibição contextualizada de informações relativas ao consumo de energia do sistema de iluminação e do laboratório, ao impacto do ambiente em termos ambientais e de custo, e exibição de informações de umidade e temperatura do ambiente.

No Dynamo, foram gerados 4 scripts de monitoramento de desempenho: 2 relativos ao consumo de energia do sistema de iluminação e 2 relativos aos dados ambientais. Os scripts divergem entre si por finalidade de monitoramento e por servidor de banco de dados utilizado.

A interface do referido ambiente de programação visual para elaboração e agrupamento das rotinas, que geraram os scripts mencionados, proporcionou acesso a pacotes de biblioteca, funcionalidades de navegação e opções de execução destes scripts nos modos manual, automático e periódico. A lógica de integração das informações consistiu em 5 passos, apontados na Figura 60 e discriminados no Apêndice E:

1. Seleção e filtro de objetos BIM alvo, equivalentes aos objetos reais do ambiente físico sob monitoramento de desempenho (azul);

2. Estabelecimento da comunicação entre o Dynamo e os servidores, e resgate e organização das informações extraídas destes servidores em sublistas (verde);

3. Agregação destas informações aos requisitos de monitoramento de condição para geração de status e relatórios (rosa);

4. Inserção destas informações nas propriedades de monitoramento criadas em cada objeto BIM alvo (violeta); e

5. Sobreposição gráfica baseada em desempenho nos objetos BIM alvo.

A seleção e filtro de objetos BIM alvo foram empregados nas Luminárias e Canaletas (que representam tridimensionalmente os circuitos), bem como nos Rooms 2D e 3D. O filtro foi configurado de acordo com a ativação manual das propriedades booleanas Energy Consumption Monitoring e/ou Environmental Monitoring. O grupo de objetos selecionados, então, passou a ser tratado individualmente para receber as informações de monitoramento em suas propriedades.

Figura 60 - Interface do Dynamo e Estrutura Lógica do Script de Integração BIM-IoT 1 4 Azul Verde Rosa Violeta Laranja

Seleção e Filtro de Objetos BIM

Comunicação, Resgate e Organização de Informações Agregação de Requisitos de Monitoramento de Condição Inserção de Informações nos Objetos BIM

Sobreposição Gráfica nos Objetos BIM

2 3

Legenda: (1) Acesso a pacotes da biblioteca do Dynamo; (2) Estrutura lógica do script; (3) Funcionalidades de navegação; e (4) Acesso às opções de execução do script.

Fonte: A autora.

Em paralelo à seleção e filtro de objetos BIM, realizou-se a comunicação entre o Dynamo e os servidores os quais as informações devem ser extraídas, a partir do emprego de dois pacotes essenciais: (i) o DynamoJSON, responsável por proporcionar a análise e organização de informações oriundas do ThingSpeak em sublistas; e/ou (ii) o SlingShot!, responsável por comunicar-se com o servidor de banco de dados SQL que abarca o banco ecmlampa, e proporciona a consulta e organização de suas informações também em sublistas. No Dynamo, as sublistas geradas por solicitação e análise (ThingSpeak), ou consulta (MySQL), representaram estruturas correlatas às apresentadas em cada banco de dados, conforme exibido nos nodes de visualização da Figura 61.

Visando a organização das informações, optou-se pela configuração de resgate sempre da informação mais atualizada, a medida que novas sublistas de entrada fossem criadas automaticamente no Dynamo.

As informações de dados ambientais do LAMPA, umidade e temperatura, foram organizadas para inserção nas propriedades dos objetos Room 2D e Room 3D. Por sua vez, as informações de consumo de energia do sistema de iluminação – potência ativa, médias de consumo e horas trabalhadas de cada luminária – foram organizadas para inserção nas propriedades de todos os objetos BIM alvo: Luminárias, Canaletas, Rooms 2D e 3D.

Figura 61 - Sublistas de Informações Geradas no Dynamo

Node de visualização com sublistas oriundas do ThingSpeak

Node de visualização com sublistas oriundas do banco de

dados MySQL Fonte: A autora.

Para cada circuito, representado tridimensionalmente pelas canaletas, atribuiu-se a somatória dos valores de potência ativa e das médias de consumo das 3 luminárias correspondentes. Para o ambiente, atribuiu-se a somatória dos valores de potência ativa e das médias de consumo dos dois circuitos – A e B.

Ademais, foi relevante resgatar os resultados dos testes estruturais de entrada e saída de dados dos bancos de dados, apresentados no 1º Ciclo de Projeto, Desenvolvimento e Avaliação. Devido às capacidades limitadas do ThingSpeak, as sublistas geradas no Dynamo incluíram informações relativas a registros datados de entrada (TimeStamp), número de entrada e valores correspondentes a umidade e temperatura em tempo real, no contexto de dados ambientais, e/ou correspondentes a potência ativa em tempo real e médias por hora e dia, no contexto do consumo de energia. Por sua vez, devido à robustez do banco de dados MySQL, as sublistas geradas incluíram informações relativas a TimeStamp, número de entrada e valores correspondentes à umidade e temperatura em tempo real, no contexto de dados ambientais, e/ou correspondentes à potência ativa em tempo real, e às médias por hora, dia, mês e ano, no contexto do consumo de energia. Além disso, foram resgatadas informações correspondentes às horas de funcionamento de cada luminária no dia. Os valores das médias de consumo por mês e ano foram relacionados a impactos econômicos e ambientais inerentes ao LAMPA, para inserção nas propriedades dos Rooms 2D e 3D.

A relação de impacto econômico foi fundamentada nas funções de cálculo de custo empregadas pela Companhia Paulista de Força e Luz (CPFL Energia), sediada em Campinas -

SP. Segundo a CPFL Energia (2017), a conta de energia inclui o ressarcimento dos seguintes custos: (i) geração de energia; (ii) transmissão e distribuição; e (iii) encargos e tributos. Os encargos e tributos envolvem o PIS/COFINS34 que incide sobre o Imposto sobre Circulação de Mercadorias e Serviços (ICMS), classificado como tributo estadual, e a Contribuição para Custeio do Serviço de Iluminação Pública (CIP), classificado como tributo municipal. Devido ao PIS/COFINS serem tributos não cumulativos, que variam de mês em mês, foram considerados os mesmos valores utilizados em CPFL Energia (2017). No caso do ICMS, o percentual de cobrança aplicado no caso da FEC-UNICAMP independe da faixa de consumo em kWh, devido a sua classe enquanto unidade consumidora, e corresponde a uma alíquota de 18%. No caso da CIP, esta taxa corresponde ao valor de R$2,80. Logo, à função de cálculo de custo foram fixados os tributos supracitados por kWh, a partir da execução inicial do cálculo das tarifas: PIS (0,86%) + COFINS (3,97%) + ICMS (18%) = R$/kWh (0,2283), sendo aplicado ao resultado da quantidade de kWh consumida. Por fim, acrescentou-se o valor da CIP (R$ 2,80). É importante reiterar que antes de empregar-se a função destacada, foi necessário transformar os valores das médias de consumo mensal e anual de Watts/h em kWh.

A relação de impacto ambiental foi embasada no fator de emissão de CO2 aplicado

sobre a faixa de consumo de energia elétrica no Brasil, apresentado pelo Ministério do Meio Ambiente (MMA, 2011). Este fator corresponde a 0.11kgCO2e/kWh. A transformação dos

valores das médias de consumo por mês e por ano em kWh também foi realizada neste caso. A agregação de requisitos de monitoramento de condição foi aplicada sobre as informações de consumo de energia, para adição de status e relatórios de desempenho nos respectivos objetos BIM. Os requisitos consistiram nas faixas ideais de operação das luminárias, definidas no 1º Ciclo de Projeto, Desenvolvimento e Avaliação. No caso do status de operação de cada circuito ser identificado como ligado (On), as informações de potência ativa de cada luminária devem estar enquadradas na faixa de operação de 49W e 64W (faixa corrigida após Avaliação Experimental do 1º Ciclo). No caso do status ser identificado como desligado (Off), as informações devem estar enquadradas na faixa de operação de 0W e 4W. Em ambos os casos, considerou-se a margem de corrente residual decorrente da possibilidade de uso de outros equipamentos do laboratório de pesquisa.

34 _{Os tributos PIS/COFINS correspondem ao Programa de Integração Social (PIS) e à Contribuição para o}

Dessa forma, os relatórios de desempenho gerados foram concebidos para abranger três situações distintas: (i) no caso de enquadramento nas faixas de operação, os relatórios apontam que as luminárias estão de acordo com o monitoramento de condição; (ii) no caso de valores superiores às faixas de operação, que correspondem a consumo excedente, os relatórios apontam que as luminárias precisam ser verificadas no local; e (iii) no caso de valores inferiores às faixas de operação, que correspondem a falhas operacionais, os relatórios também apontam que as luminárias precisam ser verificadas no local.

Além de inseridos nas propriedades das luminárias, estes relatórios repercutem nos circuitos e no ambiente. Caso uma luminária do circuito demande verificação no local, atribui-se ao circuito o mesmo feedback instrutivo. Caso contrário, atribui-se que o circuito está de acordo com o monitoramento de condição. Por sua vez, caso um circuito demande verificação no local, atribui-se ao ambiente o mesmo feedback instrutivo. Caso contrário, atribui-se que o ambiente está de acordo com o monitoramento de condição. Esta organização de informações atende aos níveis de granularidade propostos para o feedback por desagregação. Em relação às informações de dados ambientais, não foram definidos requisitos de monitoramento de condição, sendo o tipo de feedback somente informativo.

Após a organização de informações e agregação de requisitos, foi realizada a inserção

de informações nos Objetos BIM correspondentes aos objetos reais do ambiente físico sob

monitoramento de desempenho. Em níveis de desenvolvimento, as rotinas criadas até então foram executadas em modo manual para aferir o direcionamento das informações às suas respectivas propriedades. No caso das rotinas correspondentes às finalidades de consumo de energia e dados ambientais a partir de informações extraídas do banco de dados do ThingSpeak, observou-se a capacidade destas atenderem ao preenchimento de 8/16 propriedades criadas, visando a atualização de informações sobre consumo de energia; e de 5/5 propriedades criadas, visando a atualização de informações sobre dados ambientais.

A constatação relativa ao preenchimento de somente 50% das propriedades de consumo de energia retrata o reflexo das limitações identificadas no tratamento de dados no ThingSpeak para extração de informações de monitoramento (p.128). A ausência de informações acerca das médias mensal e anual de consumo desdobrou-se na ausência de informações correlatas de custo e emissões de CO2 equivalente. Nas Figura 62 e Figura 63, as

Figura 62 - Informações de Monitoramento em Room 2D e Room 3D (ThingSpeak)