Janela com algoritmo de controlo fuzzy

Um outro exemplo de controlo de janela é o “Intelligent Window Based on Embedded System” [32], desenvolvido por investigadores da Universidade de Bei- jing, China. Este sistema tem como principal curiosidade um controlo “fuzzy” ou indistinto, porque é um controlo que tem como entrada valores analógicos e define um conjunto de gamas de constantes para depois definir a saída do sistema.

Figura 2.16: Diagrama de blocos de “Intelligent Window Based on Embedded System”

A janela é composta por 3 sensores: humidade, temperatura e velocidade do vento, sendo que o valor da humidade é o que define o comportamento do sistema,

isto é, quando está a chover a janela fecha na totalidade, senão, posiciona-se de acordo com os valores obtidos pelos sensores de temperatura e da velocidade do vento, entrando como argumento do controlo “fuzzy”. Depois de definida a tabela das regras do controlo, o sistema atua na janela conforme a posição definida pela mesma tabela. A posição da janela é estimada através de 4 sensores Hall estra- tegicamente posicionados na moldura da janela. Estes sensores variam a tensão de saída de acordo com a força de um campo eletromagnético, pelo que normal- mente são construídos com materiais semicondutores e utilizados juntamente com ímanes.

A janela também é capaz de obter imagens ou fotos tiradas através do mó- dulo OV6630, que consiste numa pequena câmera fotográfica e no SAA6752HS da Phillips que é um microcontrolador capaz de obter a imagem da câmera e configu- rar a mesma através do protocolo de dois fios I2C. O buffering da imagem e todo o seu processamento é efetuado em paralelo com uma FPGA Xilinx SPARTANIIE, que obtêm os dados da imagem e guarda-os numa RAM externa. Através de uma interrupção externa, o controlador principal da janela, ARM S3C2410, lê a mais recente imagem da RAM. Este microcontrolador é também responsável por ler os valores dos sensores, logo tem também o algoritmo de controlo “fuzzy”, e saídas para controlar o motor de passo que move a janela (figura 2.16).

A janela tem também funcionalidades que podem ser exploradas pelo utiliza- dor através da internet, com um módulo DM9161 a funcionar como ponte entre a janela e a rede. O modo como o utilizador opera sobre a janela não é explícito, mas este mesmo pode mover a janela para a posição que desejar através da internet.

Todas estas diferentes soluções tem as suas vantagens e desvantagens. De- pendendo do seu propósito, todas diferem nos sensores que utilizam, porque sim- plesmente para diferentes casos diferentes grandezas interessam. Também diferem no modo como atuam, e, principalmente, na precisão da atuação. A janela com módulo GSM e a janela de automóvel confiam o controlo da posição da mesma a sensores de fim de curso. Esta atuação é imprecisa, e é possível induzir com total certeza apenas que a janela está, ou não, numa determinada posição. Este método cumpre as métricas do sistema quando não é necessária uma atuação proporcional, mas sim binária, ou “ON-OFF”. Neste tipo de atuação é necessário saber apenas se a janela está aberta ou fechada, e tudo o resto que pode estar indefinido ou, se quisermos, numa zona cega, não importa, pois o propósito é apenas ligar/desligar. Com um controlo proporcional, como nos outros dois casos, é possível saber a posição da persiana e ter um melhor controlo sobre a mesma. Com mais precisão

2.4. Controlo de janelas

no caso da janela com o flicker detector, pois usa um encoder que fornece uma resolução maior do que os quatro sensores Hall estrategicamente posicionados na janela do algoritmo “fuzzy”.

Visão global e especificação do

sistema

Como já referido, a proposta desta dissertação está inserida no âmbito do projeto Climawin. Este sistema para domótica visa essencialmente melhorar a eficiência energética de edifícios, tanto para habitações e escritórios, bem como edifícios públicos. Através da abstração à rede elétrica e ao energy harvesting por intermédio de painéis solares, as janelas do Climawin são capazes de melhorar o ambiente nesses edifícios, isto é, diversos fatores relacionados com a qualidade do ar, como por exemplo a temperatura e a humidade, e ao mesmo tempo são janelas low-power, ou seja, consomem pouca energia ao ponto e serem autónomas durante largos períodos de tempo.

Neste capítulo será explicado com mais detalhe a arquitetura do sistema, os seus métodos para atingir os objetivos mas também as restrições impingidas por diferentes parceiros do projeto.

3.1

Arquitetura do sistema

A arquitetura do Climawin resume-se a uma rede de janelas, controladas por um ZC, que por sua vez responde a pedidos provenientes de um gateway, que pode ser um mini-computador. O Climawin demo utiliza uma “Raspberry Pi” para desempenhar este último papel. A partir desta camada, é possível ligar todos os diferentes componentes do sistema à rede.

3.1. Arquitetura do sistema

Figura 3.1: Diagrama de blocos da arquitetura do Climawin

O Climawin demo tem como propósito modelar e implementar estes diferen- tes componentes e garantir a comunicação entre os mesmos. Dentro de diversas restrições e métricas, destacam-se o low-power, autonomia e comunicação sem fios entre diferentes sensores, neste caso, janelas e o controlador central.

As janelas são os dispositivos, ou “devices” e não comunicam entre si. Não é necessário pois nenhuma delas tem informação que seja relevante para outra. O propósito desta comunicação é enviar e receber informações do “Postmaster”, o Zone Controller, que tem como principal função reencaminhar mensagens proveni- entes da cloud para as janelas, e vice-versa, ou seja, enviar tramas das janelas para a cloud. Esta comunicação entre o “postmaster” e o “device” é regida pelo “Smart- Acknowledge” [19], que é uma comunicação bi-direcional do tipo “master-slave” que é aplicada uma camada acima do ERP.

A troca de informações entre o gateway e o ZC é feita través de uma ligação série sob o protocolo ESP. Esta é a ponte que liga toda a instalação à rede, ou seja, é o meio de acesso à mesma. Quer isto dizer que toda a informação que tem a cloud como destino ou origem tem de obrigatoriamente passar por este ponto. O gateway tem um papel de controlador nesta comunicação bi-direcional, e, nesta nova versão do Climawin, pode fazer pedidos ao ZC para variados efeitos.

Este gateway pode funcionar sem conexão à cloud, e garantir, mesmo assim, um funcionamento consistente da instalação Climawin e manter uma base de da- dos local atualizada. Através desta base de dados local armazenada na sua própria memória pode guardar a informação atualizada da instalação Climawin, indepen- dentemente da ligação à rede. Um exemplo aplicacional seria uma rede “Wi-fi”

local, criada através de um hotspot com ligação a qualquer dispositivo compatível com o Climawin, que seriam os pontos de acesso do utilizador ao seu sistema. Es- tes dispositivos podem ser computadores pessoais, smartphones ou tablets a correr uma aplicação especialmente desenvolvida para os seus sistemas operativos. Um website internamente alojado no gateway disponibiliza também a informação da base de dados pelo que através desta é também possível introduzir ou alterar dados no sistema.

Não obstante, a ligação à cloud é transparente, pelo que o gateway tem o papel de atualizar a base de dados colocada na nuvem computacional através dos novos dados que a base de dados local contém. No sentido inverso, tem também a responsabilidade de atualizar os dados quando é feita uma alteração na base de dados da nuvem de forma a manter ambas em sintonia.

O cenário ideal do Climawin, e é sobre essa premissa sobre a qual esta dis- sertação se apoia, é que o gateway esteja ligado à cloud, de forma a fornecer um serviço confortável ao cliente. Posto isto, daqui em diante, sempre que a cloud for referida entenda-se como um comando proveniente de uma camada superior ao gateway, usualmente associado ao cliente ou utilizador, seja da rede local ou efetivamente da cloud.