Camada de Serviço

O Projeto e o Desenvolvimento da Camada de Serviço visaram tanto o processamento dos dados sensoriados do ambiente físico, oriundos das Camadas de Sensoriamento e Rede, como o processamento da estrutura virtual de dados da edificação, oriunda do Modelo de Registro BIM. As soluções desta camada foram estruturadas com dois intuitos: as otimizações de entradas e saídas de dados no banco de dados ThingSpeak e no banco de dados MySQL.

Projeto

No ThingSpeak, as entradas e saídas são relativas aos dados sensoriados do ambiente físico. Para cada canal de recepção criado, a plataforma disponibiliza 8 campos para armazenar dados (Figura 42), assim como campos adicionais de configuração de status e

inserção de informações de localização do hardware. Diante desta restrição de armazenamento, atribuiu-se ao Canal 1 (LAMPA: Circuito A & Dados Ambientais) o propósito de abarcar as medições de corrente alternada e potência ativa das Luminárias 01, 02 e 03, além das medições de umidade e temperatura do laboratório. Por sua vez, atribuiu-se ao Canal 2 (LAMPA: Circuito B) o propósito de abarcar as medições de corrente alternada e potência ativa das Luminárias 04, 05 e 06. Para ratificação da entrada de dados nos canais definiu-se o uso dos gráficos nativos da plataforma, no sentido de controlar o número de entrada; intervalo de atualização; e última atualização de registros em cada canal.

Figura 42 - Configuração dos Canais de Recepção do Thingspeak

Fonte: A autora.

Optou-se pela manipulação e pelo tratamento dos dados armazenados através da ThingSpeak API. Entre as opções de saída de dados (JSON, XML e CSV) foi priorizada a exportação em Notação de Objetos JavaScript (JSON)25.

25 _{JSON é um formato independente e interoperável de linguagem em texto, que possibilita a inserção de dados}

No banco de dados MySQL, as entradas e saídas foram incumbidas aos dados sensoriados do ambiente físico e aos dados do Modelo de Registro BIM – este último visando a contextualização semântica do ambiente monitorado. Esse cenário conduziu à escolha da ferramenta BIM a ser utilizada para manipulação do modelo, bem como à definição de relações no banco de dados. Em relação aos dados dos sensores, definiu-se a criação, no banco de dados ecmlampa, de tabelas correspondentes a cada luminária sob monitoramento; e uma tabela correspondente ao ambiente para recepção dos valores de umidade e temperatura. No MySQL, diferentemente do ThingSpeak, as tabelas não possuem quaisquer limitações no número de campos configurados para receber dados. Além disso, determinou-se que a definição e a manipulação de dados pudessem ser efetuadas tanto no phpMyAdmin, já destacado, como no MySQL Workbench, gerenciador visual gratuito.

Ainda, indicou-se que as tabelas criadas visando o monitoramento de desempenho de luminárias e do ambiente, se relacionassem às tabelas geradas a partir da estrutura virtual de dados da edificação. Para tanto, a ferramenta BIM de modelagem definida para o protótipo deveria abarcar como recursos: (i) inserir dados do modelo em bancos de dados através do padrão de acesso Open Database Connectivity (ODBC); e/ou (ii) permitir a ligação bidirecional com quaisquer bancos de dados por meio de API. Entre as ferramentas BIM de modelagem, foram analisadas duas alternativas devido ao alto desempenho e liderança de mercado (G2 CROWD, 2016): Graphisoft ARCHICAD 20 e Autodesk Revit 2017.

Averiguou-se que o Graphisoft ARCHICAD 20 não possui os requisitos nativos necessários para sua aplicação no protótipo. A ferramenta permite a visualização da estrutura de dados do modelo BIM em tabelas, bem como a execução de consultas SQL (Query) específicas para gestão de dados (somente visualização), exibidos em um navegador web. Entretanto, a ferramenta não proporciona, para o usuário comum26, a exportação automatizada e/ou ligação bidirecional desta estrutura com um banco de dados externo – demanda desta pesquisa.

Constatou-se que o Autodesk Revit 2017, por sua vez, possui ambos os recursos: a exportação via ODBC (recurso nativo) e a ligação bidirecional por meio do Revit DBLink - add-in proprietário que possui acesso à API da ferramenta. A exportação via ODBC é viabilizada pelo MySQL Connector/ODBC (Figura 43) e toda a estrutura de dados do modelo

26 _{A Graphisoft somente disponibiliza o driver ODBC e/ou o ARCHICAD API para seus desenvolvedores}

é organizada em tabelas, constituídas por propriedades de objetos, no banco de dados externo. As novas exportações para o mesmo banco de dados sobrepõem as tabelas anteriormente criadas, assegurando que as alterações do modelo BIM sejam atualizadas. No entanto, não é possível selecionar que tabelas de dados devem ser exportadas. Por sua vez, a ligação bidirecional entre o modelo BIM e os bancos de dados contempla as ações de exportar o modelo em uma estrutura organizada em tabelas, realizar modificações e importá-los novamente na interface do Autodesk Revit. Essa ligação também é viabilizada pelo MySQL Connector/ODBC - chamado pelo próprio add-in. Seu diferencial está na funcionalidade de importação, que pode ser pré-visualizada na interface do próprio add-in e permite ao usuário definir e modificar as tabelas que devem ser importadas. Apesar das vantagens destacadas, seu uso possui limitações que podem conduzir a erros: não permite a seleção das tabelas que devem ser exportadas; apenas bancos de dados criados no MS Access (2000-2003/2007) e no SQL Server (2005/2008/2012) podem ser utilizados; e apresenta problemas de importação e exportação, quando não utilizado o mesmo banco de dados originalmente vinculado ao modelo. Destaca-se que ambos os recursos apresentados (nativo e add-in) demandam a configuração de uma Data Source Name (DSN)27_.

Figura 43 - Exportação via MySQL Connector/ODBC no Autodesk Revit 2017

Fonte: A autora.

27 _{A DSN é uma fonte de conexão ODBC que armazena os detalhes do vínculo com o banco de dados, como:}

Portanto, o Autodesk Revit foi selecionado para utilização na pesquisa, por apresentar- se como a ferramenta de modelagem BIM mais adequada aos objetivos do protótipo. Devido à demanda pela geração da estrutura virtual de dados da edificação para contextualização semântica e ao uso do MySQL 5 associado ao Apache HTTP WebServer, definiu-se o uso do recurso nativo do Autodesk Revit 2017 para interação entre o modelo BIM e o banco de dados. Para ratificação de êxito relativo à exportação, designou-se a verificação da entrada de dados no phpMyAdmin.

No âmbito dos Dados Sensoriados do Ambiente Físico, determinou-se configurações semelhantes em relação às estruturas das tabelas no banco ecmlampa, agregando-se campos: (i) para Ping, tendo em vista o controle do número de entrada de dados; (ii) TimeStamp tendo em vista os registros datados de entrada de dados; (iii) Current, Power, Temperature e Humidity, tendo em vista armazenar os valores de corrente alternada, potência ativa, temperatura e umidade, respectivamente; e (iv) Lf_Id e Room_Id, tendo em vista identificar a luminária e/ou o ambiente correspondentes, respectivamente (Figura 44). Ademais, definiu-se a atribuição de Chaves Estrangeiras (FK) aos campos de Id de ambas as tabelas, para estabelecer relação semântica com as tabelas oriundas do Modelo de Registro BIM, geradas automaticamente. O phpMyAdmin, mesma ferramenta definida para ratificação da entrada de dados no servidor, foi designado para manipular e tratar os dados armazenados no ecmlampa.

Figura 44 - Estrutura das Tabelas Primárias de Monitoramento no MySQL

Luminárias Dados Ambientais

Fonte: A autora.

Por fim, reiterou-se, tanto no ThingSpeak como no banco de dados MySQL, a consonância entre as demandas de manipulação e tratamento de dados e a estratégia de eco- feedback, para geração das informações. Dessa forma, definiu-se a relevância de interpretar os valores relativos aos dados ambientais em tempo real e relativos ao consumo de energia do sistema de iluminação em: (i) tempo real; (ii) média por hora; (iii) média por dia; (iv) média mensal; e (v) média anual. Assim, os valores relativos às médias asseguram as relações entre

consumo, custo e emissão de CO2 equivalente, e atendem aos tipos de unidades de exibição

definidos na estratégia (monetária, de energia direta e de externalidade ambiental).

Desenvolvimento

O desenvolvimento da Camada de Serviço aproveitou-se de duas bibliotecas já definidas nos software: a ThingSpeak e a WiFi.Client. No contexto do ThingSpeak, após a verificação de comunicação entre o NodeMCU e a plataforma na Camada de Rede, a mesma biblioteca efetuou uma solicitação HTTP POST para a transmissão dos dados coletados, utilizando a função ThingSpeak.writeField(). Conforme previsto em projeto, a transmissão e entrada dos dados foi ratificada na interface do próprio ThingSpeak, através de seus gráficos nativos (Figura 45).

Figura 45 - Gráficos Utilizados para Ratificar Transmissão de Dados no ThingSpeak

Fonte: A autora.

Durante os procedimentos de verificação da transmissão dos dados coletados, observou-se a limitação temporal mínima de envio para a plataforma a cada 15 segundos - já que intervalos abaixo deste limite provocaram interferência (ruído) na transmissão. Essa limitação temporal mínima desdobrou-se no incremento sequencial de registro dos dados transmitidos entre os campos do canal. Por exemplo, se o Campo 1, referente à corrente,

registrar dados às 11:30:00, o Campo 2 referente à potência somente fará seu registro de dados após 15 segundos (11:30:15), e assim por diante.

Logo, foi necessário ajustar o software para viabilizar a transmissão conjunta de dados a cada 15 segundos para todos os Campos. A retificação consistiu na substituição da função ThingSpeak.writeField() pelas funções ThingSpeak.setField() e ThingSpeak.writeFields(), que permitem direcionar e especificar os Campos em conjunto para a transmissão de dados.

No momento da exportação dos dados armazenados, foi necessário configurar a opção pelo formato em JSON e realizar o tratamento destes dados em cada campo individualmente. A estrutura de dados em JSON consiste na apresentação de sublistas referentes ao canal (channel) e seus campos (feeds). A sublista relativa ao canal abarca informações gerais de configuração. Já a sublista relativa aos campos abarca o TimeStamp e o número de controle de entrada dos dados, bem como os registros de valores oriundos dos sensores (Figura 46).

Figura 46 - Estrutura de Dados no Formato JSON Produzida no ThingSpeak

Canal 1 – LAMPA: Circuito A & Dados Ambientais Canal 2 – LAMPA: Circuito B Fonte: A autora.

As estruturas de dados em JSON geradas de cada canal receberam tratamento através da ThingSpeak API, para visualização de parâmetros como TimeZone (UTC - 03:00)

(referente a São Paulo), médias entre os valores por período de tempo e delimitação dos valores apresentados, para atender às diferentes demandas de exibição visando a camada de interface. Esse tratamento foi executado com o uso de Parâmetros de Feed, que contemplam operações matemáticas, localização, status do feed, período de consulta, resultados e exibição das chaves de leitura.

Diante dessa demanda de manipulação e tratamento de dados, foram realizados testes estruturais apresentados a seguir, na Subseção 4.2.2 – Avaliação: 1º Ciclo. Os testes apontaram limitações na ThingSpeak API, associadas à capacidade de apresentar as saídas de dados para a interface somente em três níveis de informação definidos em projeto: tempo real; média por hora e média por dia.

No contexto do MySQL, após a verificação de comunicação entre o NodeMCU e o banco de dados na Camada de Rede, definiu-se no script em PHP os comandos SQL de escrita dos dados no banco ecmlampa. Ademais, identificou-se a demanda de replicá-lo por 7, no intuito de atender ao direcionamento de dados para cada tabela criada conforme projeto (Luminárias de 01 a 06 e Dados Ambientais). Esse procedimento desdobrou-se no fato de que, a função criada no NodeMCU para identificar o script em PHP passou a ser executada 7 vezes, resultando na ampliação do intervalo de tempo entre as leituras de dados. Anteriormente, esse intervalo estava balizado pelo ThingSpeak (15 segundos). Devido a esta demanda, o intervalo atingiu a faixa mínima de 105 segundos entre as leituras registradas.

Por sua vez, a exportação de dados do Modelo de Registro BIM para o banco ecmlampa resultou em um montante de 218 tabelas geradas automaticamente, já relacionadas entre si e constituídas por propriedades inerentes aos objetos BIM existentes. Aplicou-se um filtro sobre essa estrutura de dados visando somente as tabelas associadas aos objetos sob monitoramento e suas relações. As tabelas filtradas representaram 5% desse montante.

Ambos os tipos de registros – oriundos da RSSF e do Modelo de Registro BIM – assim como as relações estabelecidas entre as tabelas para contextualização semântica e geração da informação, foram verificados através do phpMyAdmin, mediante a execução de consultas SQL e acesso ao diagrama de relacionamentos entre tabelas. Observa-se que os registros inerentes às tabelas de monitoramento são dinâmicos, inseridos periodicamente, em tempo real, e de modo automatizado. Já os registros inerentes às tabelas de dados da edificação são estáticos, inseridos de modo automatizado, mas dependentes de ação do usuário.

A Figura 47 apresenta um recorte do diagrama de relacionamento entre tabelas produzido no phpMyAdmin, explicitando exemplos de tabelas criadas manualmente para receber dados sensoriados do ambiente físico (ex. ecm_lamp01 a 06 e ecm_environmental) e tabelas oriundas do Modelo de Registro BIM (ex. rooms) geradas automaticamente.

Por sua vez, a Figura 48 enfatiza este relacionamento por Chave Estrangeira (FK), destacando as tabelas de monitoramento de dados ambientais do LAMPA e de consumo de energia da Luminária 01, respectivamente, preenchidas e vinculadas pelos campos de Id (ecm_room_id) à tabela de ambientes oriunda do Modelo de Registro BIM.

Figura 47 – Recorte do Diagrama de Relacionamento entre Tabelas

Fonte: A autora.

Figura 48 - Tabelas de Monitoramento de Dados Ambientais (Acima) e de Consumo da Luminária 01 (Abaixo) Relacionadas por FK com Tabela de Ambientes do Modelo BIM (Centro)

Assim como no ThingSpeak, devido às demandas de manipulação e tratamento de dados, foram realizados testes estruturais apresentados a seguir, na Subseção 4.2.2 – Avaliação: 1º Ciclo. Os testes corroboraram a robustez do banco de dados MySQL e apontaram sua capacidade de apresentar as saídas de dados para a Camada de Interface em todos os níveis de informação definidos em projeto. Logo, ambos os serviços – ThingSpeak e banco de dados MySQL – foram configurados para o processamento de dados e evidenciadas suas diferenças estruturais na saída das informações geradas para a interface.

Assim, enfatiza-se como produto da Camada de Serviço a geração de informações, de acordo com a estratégia de eco-feedback empregada, para alimentar a Camada de Interface.