Post - Domótica

Introdução

Desde a revolução industrial quando surgiram as primeiras automações nas linhas de produção, as tecnologias nas suas mais variadas formas, antes empregadas na indústria, vêm evoluindo e se tornando parte de outros cenários como as casas e edifícios residenciais, dando origem ao termo automação residencial. A automação residencial emprega tecnologias ao ambiente doméstico com o principal objetivo de propiciar conforto, segurança, praticidade, produtividade, economia, eficiência e rentabilidade valorizando o empreendimento e seus usuários. Neste trabalho esse contexto será criado e ilustrado com os recursos tecnológicos disponíveis atualmente.

Tecnologias

• A tecnologia X10 foi uma das precursoras na área de automação residencial, servindo de base para o surgimento de outras tecnologias comercializadas atualmente. Esta tecnologia foi criada na década de 70 pela empresa Pico Eletronics, na Escócia. A X10 utiliza a rede elétrica existente para comunicação com o dispositivo automatizado e sua versatilidade é limitada por possuir poucas funções simples como liga/desliga e dimerização de luzes, porém, ainda assim em muitos países esta tecnologia é empregada por ser composta de produtos baratos e de fácil instalação proporcionando inclusive sua comercialização em casas de material de construção[3].

Outra tecnologia empregada em automação residencial é a Zigbee que segundo especialistas é uma tendência de mercado. Esta ainda está em fase de desenvolvimento por um grupo de empresas como a Honeywell, Philips, Samsung, Motorola, Cisco Systems, Eaton, Crestron, Legrand, LG, NEC, Epson e Texas Instruments. Sua principal característica é o baixo consumo de energia já que um módulo pode funcionar por até 6 meses com o uso de pilhas comuns. A comunicação de dados é feito via wireless e seu controle é descentralizado. O protocolo é proprietário e de mão dupla (envia/recebe) e possui o mesmo nome da tecnologia. A topologia de rede é na forma de malha onde vários dispositivos trabalham em conjunto comunicando entre si formando uma rede wireless de baixa largura de banda com tecnologia de controle de rede que opera no padrão 802.15.4[3].

• Raspberry PI

O raspberry PI é um microcomputador desenvolvido na Grã-Bretanha de escala reduzida com capacidade computacional equiparável à de desktops comuns podendo executar softwares de edição de textos e planilhas, processamento de jogos, navegação à internet, entre outros. Este microcomputador possui um processador ARM11 de 700 MHz, memória RAM (Random Access Memory) de 512 MB, placa de rede onboard, duas saídas de vídeo (HDMI - High-Definition Multimedia Interface e RCA - Radio Corporation of America), saída de áudio, entrada para cartão SD (Secure Digital) e duas portas USB (Universal Serial Bus) 2.0. Com tantos atributos, este microcomputador possui alta versatilidade de aplicações já que pode rodar um sistema operacional a partir de um cartão SD dispensando um HD (Hard Disk) de proporções maiores[4].

• Arduino

O arduino é uma placa de prototipação open-source muito utilizada em aplicações de instrumentação e robótica por possuir um microcontrolador muito versátil o qual permite o controle de muitos dispositivos[4]. O microcontrolador é um atmega produzido pela Atmel muitos modelos possuem conversor analógico-digital, interface de comunicação serial, portas de I/O digitais e analógicas[5].

Proposta de uma Implementação Machine-to-Machine (M2M)

O que é M2M? Foram feitas muitas tentativas para uma definição simples do termo M2M como Machine-to-Mobile (Máquina para celular), Machine-to-Man (Máquina pra Homem), Machine-to-Machine(M2M), etc. A forma mais básica para descrever M2M é ilustrada na figura abaixo:

O objetivo de uma solução como esta é de estabelecer as condições necessárias pelas quais torna-se possível que um dispositivo troque informações (de forma bidirecional) com uma aplicação por meio de uma comunicação de rede de forma que a aplicação ou o dispositivo aja como a base dessa troca de informação. Dentro desse contexto, a comunicação em rede tem um papel fundamental: o estabelecimento de uma relação de M2M entre a aplicação e o dispositivo. Uma outra definição como em muitos casos, o conceito M2M incorpora um grupo de dispositivos similares como na figura abaixo:

Um exemplo que ilustra a figura acima seria o caso do gerenciamento de uma frota onde os dispositivos da figura seriam caminhões e a rede de comunicação seria a rede celular. Em outros casos os dispositvos podem não interagir de forma direta com a aplicação cuja capacidade (seja processamento ou outra natureza) seja limitada. Nestes cenários, o relacionamento é intermediado por outro dispositivo (isto é, um gateway) que promove de alguma forma a consolidação da comunicação. Este exemplo é ilustrado na figura 1.3 abaixo:

"Medição inteligente" é um exemplo de tal aplicação onde os dispositivos são medidores inteligentes e a rede de comunicação pode ser uma rede celular ou a internet.

Cenários

Na grande maioria das soluções M2M, um grande número de dispositivos comunica com um servidor central. Um exemplo de comunicação device-to-server (dispositivo para servidor) que ilustraria esse cenário poderia ser o de uma grande concessionária de energia que coletasse remotamente dados de medição de seus clientes. Em um verdadeiro cenário device-to-server, um operador de rede pública proveria a conectividade entre os dispositivos M2M e o servidor M2M. Um outro tipo de cenário seria o caso de dispositivos M2M comunicarem uns com o outro diretamente sem envolver o servidor central. Embora este cenário seja possível, seu uso é muito menos frequente ou muito incomum nas soluções de M2M, porem futuramente, cada vez mais dispositivos M2M diferentes se conectarão e as possibilidades de um cenário device-to-device (dispositivo para dispositivo) aumentarão. A figura a seguir ilustra esses dois cenários:

Em cenários cuja área automatizada possui vários dispositivos M2M, é comum e benéfico a adoção de um gateway (M2M GW). Com um gateway, muitos dispositivos podem compartilhar uma única conexão através de uma rede pública. Para a comunicação entre os dispositivos M2M e o servidor central, uma rede local pode ser usada (LAN Local Area Network).

A proposta de implementação de uma solução M2M contemplará este último cenário, porém, possuindo apenas um dispositivo e substituindo a rede Telecom por uma rede local (LAN - Local Area Network).

Especificação de um case:

Para mostrar o conceito na prática um case será especificado.
Serão necessários:
Hardware:
- um notebook ou desktop
- um dispositivo com browser e que se conecte via wifi
- um roteador wifi
- placa de desenvolvimento arduino
- shield ethernet para a placa de desenvolvimento arduino
- cabo de rede ethernet
- lâmpada incandescente
- ventilador
- atuador

Software:
- IDE eclipse
- IDE arduino
- WebContainer (Tomcat)
- Firmware que será executado no arduino
- Software que será executado no servidor

Descrição/uso de cada componente descrito acima:

Hardware:
- Notebook ou desktop: será usado como servidor no qual residirá o software que processará as requisições dos clientes e que comunicará com a placa arduino via wifi.
- um dispositivo com browser e que se conecte via wifi: servirá como cliente o qual fará requisições para controlar a parte automatizada.
- um roteador wifi: será o equipamento que providenciará uma LAN na qual tudo estará conectado, isto é, a placa arduino, o servidor e o cliente.
- placa de desenvolvimento arduino: dispositivo automatizador.
- shield ethernet para a placa de desenvolvimento arduino: placa necessária para conectar a placa arduino a uma rede via cabo ethernet.
- cabo de rede ethernet: conectará o shield ethernet ao roteador wifi.
- lâmpada incandescente: dispositivo a ser automatizado.
- ventilador: dispositivo a ser automatizado.
- atuador: placa para ligar ou desligar dispositivos, neste caso, a lâmpada e o ventilador.

Software:
- IDE eclipse: utilizado para desenvolver a aplicação do servidor.
- IDE arduino: utilizado para desenvolver o firmware da placa arduino.
- WebContainer (Tomcat): utilizado para publicar o website contendo a interface gráfica para o usuário.
- Software que será executado no servidor: software que fará o processamento das requisições dos clientes que se comunicará com a placa arduino via wifi.
- Firmware que será executado no arduino: firmware que processará as requisições do servidor e enviará comandos para o atuador.

Um website deverá ser criado e hospedado em uma máquina a qual será o servidor. O website deverá prover a interface gráfica para dar condições ao usuário para que este controle os equipamentos automatizados.
Qualquer dispositivo com um browser poderá acessar esse website pela intranet e nesta ocasião será o cliente.

Dinâmica:

Um cliente acessará o website com a interface de controle dos equipamentos automatizados. Esta interface é composta simplesmente de uma tabela com os campos auto-explicativos: dispositivo, comando e status. O cliente clica no botão mudar status para ligar a lâmpada ou o ventilador. Uma requisição é enviada do cliente (celular, desktop, notebook, tablet, ipad, etc) ao servidor pelo wifi. O servidor recebe a requisição e a processa e então estabelece uma conexão com a placa shield ethernet e envia comandos para ligar o dispositivo em questão. A placa shield ethernet recebe a requisição e a redireciona como informação para a placa arduino processar. Esta por sua vez, processa e envia comandos ao atuador que liga ou desliga o equipamento a ele conectado. Para melhor exemplificar, segue a figura abaixo:

Implementação do case

Para a implementação do case, foram necessárias a execução das seguintes tarefas:

- Implementar o código do servidor que inclue o website, a lógica de negócio (processamento das requisições) e o protocolo que estabele também uma comunicação via socket com a ponta.
- Implementar o código da ponta que inclui a parte de conexão de rede e a parte de processamento das requisições provenientes do servidor, bem como a parte de atuação (controle dos componentes automatizados).
- Ligar todos os integrantes da solução por meio de roteador wifi.
- Publicar o website em um web container (Tomcat 7.0).
- Dispor de um celular com conexão wifi para requisitar o website do servidor pela intranet criada pelo roteador wifi.

Proposta para trabalhos futuros

Dispositivo automatizador na ponta:
O dispositivo da ponta é uma placa de desenvolvimento arduino. Este dispositivo dispõe de portas como meio de interação com o meio exterior.
A portas são de dois tipos:
- Analógicas: para leituras analógicas.
- Digitais: para leitura e escrita digitais bem como para o uso do recurso de saída digital em modulação PWM para controle de pontência às cargas.

Na ponta deve rodar um firmware com funções variadas para facilitar o domínio total dos recursos do dispositivo:
- permitir que o servidor configure suas portas nas funções possíveis como descritas acima.
- permitir a visualização de configuração das portas podendo esta ser uma listagem.
- permitir o agendamento de tarefas em datas e horários estipulados.

O firmware deve dispor de um protocolo de comunicação com o servidor. Este protocolo deve expor de forma intuitiva e clara ao servidor as funções descritas anteriormente.
Como o arduino é usado como um dispositivo automatizador de propósitos gerais, fica evidente que para conseguir determinadas automatizações, circuitos complementares devem ser desenvolvidos para atuarem nas cargas. Nesse sentido, estes circuitos são o que se chama de atuadores, porquanto é impossível que o sinal da porta do arduino consiga ligar um ventilador ou uma lâmpada, ou qualquer outra carga que demande mais do que 40 mileamperes de corrente. A figura anterior ilustra o atuador como parte integrante da solução.

Servidor:
O servidor é a parte centralizadora de todas as requisições de ambas as partes (clientes e pontas).
Para a comunicação do servidor com a ponta, o código deve possuir o protocolo descrito anteriormente.
Na solução aqui proposta, a ponta é o arduino, porém, esta poderia ser qualquer outra plataforma de desenvolvimento como o raspberry, neste caso, o servidor teria que ter um protocolo específico de comunicação com o raspberry. Uma vez definido e implementado os protocolos para diversos dispositivos diferentes, o servidor passa a ter suporte para todos eles, de forma que o mesmo pode identificar um novo dispositivo e verificar se possui o protocolo para a comunicação com o mesmo. Assim, a solução apenas cresceria em "corpo" a medida que novas funcionalidades fossem sendo acrescentadas por meio de colaboração ou qualquer outro meio.
O servidor deve dispor de um website para servir de interface de interação entre a solução e o usuário. Assim, qualquer informação proveniente do website seria enviada ao servidor onde este processaria e por meio do protocolo de comunicação, enviaria os comandos de controle para as pontas.

Considerações finais

De acordo com a informações dispostas neste trabalho, fica claro o que se pode fazer com as tecnologias disponíveis. O grau de automação que se consegue atualmente é enorme. Muitas outras aplicações podem surgir e serem facilmente implementáveis. O que o futuro nos reserva em termos de tecnologia é com certeza algo grandioso e ao que tudo indica, tudo estará conectado à rede mundial, a internet. Poderemos acessar tudo de qualquer lugar. É uma tendência que está cada vez mais próxima.

Referências

• [1] Sistemas de Automação Residencial de baixo custo uma realidade possível. Cabral, Michel Madson Alves, Campos, Antonio Luiz Pereira de Siqueira. CEFET – RN. 2008.
• [2] Dias, César Luiz de Azevedo, Pizzolato, Nélio Domingues. Domótica. Aplicabilidade e Sistemas de Automação Residencial.
• [3] Principais tecnologias de automação residencial comercializadas no Brasil e suas características. Teruel, Evandro Carlos, Novelli Filho, Aristides. CEETEPS – SP.
• [4] Desenvolvimento de um Sistema para Adaptação de Contexto em Automação Residencial. Silva, Eduardo Germano. UFSC - SC. 2013
• [5] Uma Alternativa Simplificada de Dispositivos Eletrônicos Utilizados em Automação Residencial. Mota, Ricardo Lins, Silva, Wilton Lacerda. FAINOR - BA. 2008.
• [6] M2M Communications A System Approach. Boswarthick David, Elloumi Omar, Hersent Olivier. 2012