LoRa é uma tecnologia de comunicação sem fio para longa distancias e baixo consumo de energia para isso ela usa ondas de rádio, sendo implementada em estruturas de dispositivos iot a bateria ou a uma fonte de energia.

estabelecida em 2015 a lora aliance desenvolve o lorawan, o protocolo de comunicação usado pelos dispositivos lora.

Em sua estrutura existem:

End Devices: sensores ou atuadores enviam mensagens sem fio moduladas para os gateways ou recebem mensagens sem fio de volta dos gateways, essa comunicação usa o protocolo lorawan

Gateways - receba mensagens de dispositivos finais e as encaminhe para o Network Server em um novo protocolo

Network Server: um software executado em um servidor que gerencia toda a rede

Application servers: um software executado em um servidor responsável pelo processamento dos dados para os aplicativos
 

frequências regionais
 

a lora aliance determina frequências licenciadas para a comunicação dos dispositivos lora em cada pais.

lora classes

esses dispositivos por serem half duplex não podem enviar e receber  dados ao mesmo tempo, podendo realizar apenas uma ação de cada vez, as maneiras como esses métodos de recebimento de dados são divididos em 3 classes

classe A: com o menor consumo de energia mas apenas abre uma( ou duas dependendo da configuração) janelas de tempo (rx) para receber informações do gateway logo após realizar o uplink
 

classe B: abre janelas pre determinadas em momentos específicos essas janelas são agendadas pelo próprio gateway

classe c: mantem a comunicação sempre aberta para comunicação, porem consome mais energia que as outras classes

Referencias

https://www.thethingsnetwork.org/docs/lorawan/

https://consultimer.com/o-que-e-lora-conheca-a-tecnologia-de-radiofrequencia-de-longo-alcance/

https://lora-alliance.org/

https://www.researchgate.net/figure/Graphical-description-of-the-three-LoRaWAN-classes_fig1_351889574

[ID:120] Autor:Lorena Maria Costa do Nascimento - Criado em: 2022-06-29 16:42:36 - [ Compartilhar ]

LoRa é uma tecnologia de comunicação sem fio para longa distancias e baixo consumo de energia para isso ela usa ondas de rádio, sendo implementada em estruturas de dispositivos iot a bateria ou a uma fonte de energia.

estabelecida em 2015 a lora aliance desenvolve o lorawan, o protocolo de comunicação usado pelos dispositivos lora.

Em sua estrutura existem:

End Devices: sensores ou atuadores enviam mensagens sem fio moduladas para os gateways ou recebem mensagens sem fio de volta dos gateways, essa comunicação usa o protocolo lorawan

Gateways - receba mensagens de dispositivos finais e as encaminhe para o Network Server em um novo protocolo

Network Server: um software executado em um servidor que gerencia toda a rede

Application servers: um software executado em um servidor responsável pelo processamento dos dados para os aplicativos
 

frequências regionais
 

a lora aliance determina frequências licenciadas para a comunicação dos dispositivos lora em cada pais

lora classes

esses dispositivos por serem half duplex não podem enviar e receber  dados ao mesmo tempo, podendo realizar apenas uma ação de cada vez, as maneiras como esses métodos de recebimento de dados são divididos em 3 classes:

classe A: com o menor consumo de energia mas apenas abre uma( ou duas dependendo da configuração) janelas de tempo (rx) para receber informações do gateway logo após realizar o uplink
 

classe B: abre janelas pre determinadas em momentos específicos essas janelas são agendadas pelo próprio gateway

classe c: mantem a comunicação sempre aberta para comunicação, porem consome mais energia que as outras classes

Referencias

https://www.thethingsnetwork.org/docs/lorawan/

https://consultimer.com/o-que-e-lora-conheca-a-tecnologia-de-radiofrequencia-de-longo-alcance/

https://lora-alliance.org/

https://www.researchgate.net/figure/Graphical-description-of-the-three-LoRaWAN-classes_fig1_351889574

[ID:119] Autor:Mateus Cordeiro dos Santos - Criado em: 2022-06-29 16:32:52 - [ Compartilhar ]

Definição

               A SigFox foi desenvolvida por uma empresa francesa, que leva o mesmo nome, com o intuito de conectar todos os objetos do mundo físico ao universo digital. A SigFox trata-se de uma rede global dedicada à Internet das Coisas (IoT), baseada em baixo consumo de energia, longo alcance e dados que oferecem um serviço de conectividade de ponta a ponta.

Princípios da tecnologia

Ultra-Narrow Band (UNB):

                    A rede Sigfox usa a técnica de Ultra-Narrow Band para a transmissão de mensagens. Esta técnica usa canais de 100Hz de largura de banda nas regiões ETSI e ARIB (Europa, Japão), e de 600Hz na região FCC (Américas, Oceania).

Figura 1 – A rede Sigfox é baseada em Ultra-Narrow Band

           A tecnologia Ultra Narrow Band se caracteriza por um uso ótimo da potência disponível, o que permite que os dispositivos Sigfox se comuniquem por longas distâncias de forma confiável, mesmo em canais com interferências e ruídos.

         A faixa de frequência utilizada depende da região. Na Europa, por exemplo, é usada a faixa entre 868 e 868,2 MHz. Já no resto do mundo é usada a faixa entre 902 e 928 MHz, havendo restrições de acordo com a regulamentação local.

Acesso Aletório ao Canal / Diversidade 

      O acesso aleatório é um recurso fundamental para alcançar uma alta qualidade de serviço, a transmissão não está sincronizada entre a rede e o dispositivo. O dispositivo envia a mensagem em uma frequência aleatória e em seguida envia 2 réplicas em diferentes frequências e tempo, criando diversidade de tempo e frequência.  Esta diversidade aumenta muito a resistência do sistema a interferências pois uma mesma mensagem tenta vários “caminhos” – frequências e tempos diferentes para garantir a recepção bem-sucedida da mensagem.

Figura 2 –  Salto de frequência nas repetições (ETSI)

Recepção cooperativa

      Na recepção cooperativa um objeto não está vinculado a uma estação base específica, ao contrário dos protocolos celulares. A mensagem emitida é recebida por uma estação base próxima e, em média, o número de estações base é de 3. Isso é chamado de “diversidade espacial”. Diversidade espacial, juntamente com a diversidade de tempo e frequência das repetições, são os principais fatores por trás da alta qualidade de serviço da rede Sigfox.

Figura 3 – Mensagem recebida por múltiplas estações base Sigfox

Mensagens Pequenas

             Para atender as restrições de autonomia de bateria e custo dos objetos conectados,  o protocolo  Sigfox é otimizado para mensagens pequenas. O tamanho da mensagem vai de 0 a 12 bytes. Embora a princípio isto pareça pouco, com uma mensagem de até 12 bytes é o suficiente para a maioria das aplicações de IoT para objetos simples. Com 132 Bytes é possível enviar informações de sensores, eventos, coordenadas de GPS e dados da aplicação. 

Tabela 1 – Exemplos de mensagens

Principais características da rede Sigfox

Visão geral da arquitetura de rede:

A rede Sigfox possui uma arquitetura horizontal e estreita, composta por 2 camadas principais:

Figura 4 – Arquitetura da rede Sigfox

Visão geral da arquitetura de rede

      A camada Network Equipment consiste essencialmente em estações base responsáveis pelo recebimento das mensagens enviadas pelos dispositivos e envio das mesmas para a camada Sigfox Support Systems. A camada Sigfox Support System constitui a rede principal sendo encarregada de processar as mensagens e enviá-las através de callbacks para o sistema do cliente.  A camada Sigfox Support System inclui módulos e recursos que são essenciais para garantir a implantação, operação e o monitoramento da rede, como o sistema de suporte empresarial para pedidos e cobranças, e suporte de rádio para garantir o bom funcionamento da rede. A comunicação entre as camadas é feita através da Internet por uma conexão VPN.

Arquitetura de rede plana

    A arquitetura plana da rede Sigfox é a chave para reduzir os custos de investimentos e operacional. O Software Defined Radio (SDR) Sigfox ajuda a reduzir os custos das estações base e a aumentar sua flexibilidade. Nesta arquitetura a operadora Sigfox – no Brasil a WND – entrega aos seus parceiros as camadas de rede intermediárias prontas para uso. Cabe ao desenvolvedor a criação da aplicação na nuvem e a escolha ou criação dos dispositivos que pretende usar. Não há necessidade de se preocupar com a compra de gateways, sua instalação e manutenção planejamento de RF, contratação e estabelecimento de backhaul, criação de um servidor para receber mensagens em tempo real, etc.

Figura 5 – Arquitetura plana

Alta capacidade de rede

    A rede Sigfox possui uma alta capacidade de rede permitindo a escala de bilhões de objetos conectados. Essa capacidade de rede são resultados dos seguintes fatores:

•A modulação ultra-narrow band tem o benefício de eficiência no espectro e resistente a interferências, enquanto toda a energia é concentrada em uma largura banda muito pequena;

•Diversidade de tempo e frequência, introduzida pelo acesso aleatório;

•Diversidade espacial devido às células de rede sobrepostas.

Figura 6 – Combinação de especificações Sigfox resulta em uma alta capacidade da rede

      Outra vantagem é que a capacidade é a mesma independentemente do link de rádio, enquanto outras redes têm uma capacidade decrescente à medida que a qualidade do link de rádio piora:

Figura 7  – Capacidade de manutenção independentemente da qualidade do link de rádio

Alta eficiência energética

            A alta eficiência energética permitida pela tecnologia Sigfox permite que os parceiros produzam chips que consomem de 10 mA a 50 mA durante a transmissão. Esse valor vai depender do chip utilizado. A figura a seguir exibe o consumo em durante a comunicação e tempo inativo:

Figura 8 – Baixíssimo consumo aumenta o tempo de bateria (região FCC)

Longo alcance

        Uma das principais vantagens competitivas da tecnologia Sigfox está na grande cobertura possível e com um número relativamente pequeno de estações base. Esta vantagem deriva de:

•O “link budget” muito bom da tecnologia Sigfox. Ele indica quanto o sinal pode ser atenuado e ainda assim se ter uma recepção perfeita. Na tecnologia Sigfox o link budget é de 158dB, da mesma ordem de LTE e NB-IOT;

•A Taxa de dados propositalmente limitada a menos que 600bps aumenta a sensibilidade do receptor e a chance de uma recepção adequada; boa cobertura indoor, devido ao uso de banda sub-GHz.

Figura 9 – Link Budget Sigfox (região FCC)

Resiliência a interferências

           A tecnologia Sigfox apresenta capacidades anti-jamming únicas, devido à robustez intrínseca da UNB, juntamente com a diversidade espacial das estações de base (+20 dB). A melhor prova da alta resiliência aos interferentes é a capacidade de transmitir apesar da presença de sinais de interferência. A modulação de banda ultra-estreita tem uma certa robustez intrínseca porque a sobreposição com o ruído é muito baixa. Para que uma mensagem seja recebida, o sinal deve ser pelo menos 8 dB acima do nível de ruído, conforme exibido na figura a seguir:

Figura 10 – Capacidades anti-jamming provida pela UNB

Segurança

         Com base em sua experiência e suas parcerias, a Sigfox aplicou a segurança por princípios de design em todas as etapas de definição do seu protocolo e no desenvolvimento de sua infra-estrutura. Isso abrange a cadeia IoT completa, incluindo dispositivos, infraestrutura de rede e serviços baseados na nuvem:

Figura 11 – Segurança por padrão

Referências Bibliográficas

EMBARCADOS. Uma visão técnica da Rede SigFox. Disponível em: https://www.embarcados.com.br/uma-visão-tecnica-da-rede-sigfox/. Acesso em: 15 jun. 2022.

SIGFOX. Nossa História. Disponível em: https://www.sigfox.com/en/sigfox-story. Acesso em: 15 jun. 2022.

[ID:118] Autor:Leonardo Bozza - Criado em: 2022-06-29 15:00:25 - [ Compartilhar ]

RESUMO

Para este projeto de integração e facilitação de gerenciamento de horários de alarmes em escolas (ou outra aplicação semelhante como turnos de escritórios e indústrias) foi desenvolvida uma interface onde é possível acionar, remotamente, o atuador que comanda a sirene, ligada à uma placa que condiciona o sinal para o alto-falante piezoelétrico. A conectividade e gerenciamento ficam à cargo de um ESP32, a programação foi realizada em IDE Arduino e NodeRED. O protocolo de comunicação escolhido foi o MQTT, via Wi-Fi disponível no campus e no local de testes/desenvolvimento.

OBJETIVO 

O objetivo é permitir que o disparo da sirene seja automatizado com o preenchimento de um banco de dados com os horários que cada sirene deve ser acionada. Uma vez programado os dias e horários de cada sirene no banco, o disparo ocorrerá sem interferência do usuário, que também pode acionar manualmente fora dos horários programados e alterar o volume.

METODOLOGIA

O sistema, baseado em plataformas open source e open hardware, usa uma sirene piezoelétrica de central de alarme residencial, recuperada de sucata. Um protótipo foi elaborado e montado em placa de matriz de contatos, sendo acionada por módulo de relês comandado pelo ESP32. Recebendo o sinal de disparo ou no horário programado, o relê é acionado e a sirene é ligada por um tempo programado no ESP e desliga após esse tempo. O teste do sistema foi feito tanto pelo botão da interface para acionamento manual quanto usando horários programados. Os horários são baseados no horário GMT que é obtido da rede pelo ESP no momento da conexão.

CONCLUSÃO

O projeto se mostrou não só estável, mas também relativamente simples e barato para implementação e escalabilidade, permitindo que várias unidades operem concomitantemente na mesma rede ou até mesmo em redes diferentes, se houver necessidade, permitindo o uso em plantas industriais diferentes e o controle e programação de horários de turno por um RH central. Também é necessário destacar a agilidade em mudanças de horários que o sistema pode fornecer, diminuindo o custo com pessoal de monitoramento de horário e também para funções de segurança, como toques personalizados paca incêndios, terremotos, evacuações de emergência, perigos químicos, biológicos e outras ameaças, sendo uma ferramenta a favor da segurança e integridade física dos ocupantes dos locais de instalação.

[ID:115] Autor:Daniel Gustavo de Souza Rodrigues - Criado em: 2022-06-29 13:06:32 - [ Compartilhar ]

A Toradex é uma empresa suiça que projeta e desenvolve computadores em módulo (CoM) ou sistemas em módulo (SoM) juntamente com placas base e acessórios compatíveis para o mercado de sistemas embarcados. É uma empresa que fornece produtos e suporte gratuito.

Os produtos fornecidos pela empresa podem ser usados em diversas aplicações entre elas pode-se citar indústria robótica e de automação, assistência médica, transporte, veículos e agricultura, testes e medições e Smart city.

Dentre a gama de produtos existentas na empresa Toradex, aqui aborda-se a placa base Aster (Figura 1).

Figura 1: Placa base Aster

Fonte: TORADEX.

Esta é uma placa da família Colibri, na Toradex existem três famílias, possui pinos compatíveis com Arduino e Raspberry Pi, o que possibilita integração entre elas, logo o aproveitamento de projetos, por exemplo.

As maiores vantagens dessa placa se devem ao fato de ser uma placa robusta, podendo ser implementada em ambientes mais críticos, além de ter suporte técnico completo e gratuito fornecido pela empresa, possui também uma longa vida útil e uma plataforma escalável, ou seja, de migração rápida. 

[ID:114] Autor:Gabriela de Lima Kido - Criado em: 2022-06-29 02:20:02 - [ Compartilhar ]

SIGFOX

Definição 

A SigFox foi desenvolvida por uma empresa francesa, que leva o mesmo nome, com o intuito de conectar todos os objetos do mundo físico ao universo digital. A SigFox trata-se de uma rede global dedicada à Internet das Coisas (IoT), baseada em baixo consumo de energia, longo alcance e dados que oferecem um serviço de conectividade de ponta a ponta. 

Princípios da tecnologia 

Ultra-Narrow Band (UNB): 

                    A rede Sigfox usa a técnica de Ultra-Narrow Band para a transmissão de mensagens. Esta técnica usa canais de 100Hz de largura de banda nas regiões ETSI e ARIB (Europa, Japão), e de 600Hz na região FCC (Américas, Oceania). 

Figura 1 – A rede Sigfox é baseada em Ultra-Narrow Band 

A tecnologia Ultra Narrow Band se caracteriza por um uso ótimo da potência disponível, o que permite que os dispositivos Sigfox se comuniquem por longas distâncias de forma confiável, mesmo em canais com interferências e ruídos. 

         A faixa de frequência utilizada depende da região. Na Europa, por exemplo, é usada a faixa entre 868 e 868,2 MHz. Já no resto do mundo é usada a faixa entre 902 e 928 MHz, havendo restrições de acordo com a regulamentação local. 

  

Acesso Aletório ao Canal / Diversidade  

      O acesso aleatório é um recurso fundamental para alcançar uma alta qualidade de serviço, a transmissão não está sincronizada entre a rede e o dispositivo. O dispositivo envia a mensagem em uma frequência aleatória e em seguida envia 2 réplicas em diferentes frequências e tempo, criando diversidade de tempo e frequência.  Esta diversidade aumenta muito a resistência do sistema a interferências pois uma mesma mensagem tenta vários “caminhos” – frequências e tempos diferentes para garantir a recepção bem-sucedida da mensagem. 

Figura 2 – Salto de frequência nas repetições (ETSI) 

Recepção cooperativa 

      Na recepção cooperativa um objeto não está vinculado a uma estação base específica, ao contrário dos protocolos celulares. A mensagem emitida é recebida por uma estação base próxima e, em média, o número de estações base é de 3. Isso é chamado de “diversidade espacial”. Diversidade espacial, juntamente com a diversidade de tempo e frequência das repetições, são os principais fatores por trás da alta qualidade de serviço da rede Sigfox. 

Figura 3 – Mensagem recebida por múltiplas estações base Sigfox 

Mensagens Pequenas 

             Para atender as restrições de autonomia de bateria e custo dos objetos conectados, o protocolo Sigfox é otimizado para mensagens pequenas. O tamanho da mensagem vai de 0 a 12 bytes. Embora a princípio isto pareça pouco, com uma mensagem de até 12 bytes é o suficiente para a maioria das aplicações de IoT para objetos simples. Com 132 Bytes é possível enviar informações de sensores, eventos, coordenadas de GPS e dados da aplicação.  

Tabela 1 – Exemplos de mensagens 

Principais características da rede Sigfox 

Visão geral da arquitetura de rede: 

A rede Sigfox possui uma arquitetura horizontal e estreita, composta por 2 camadas principais: 

Figura 4 – Arquitetura da rede Sigfox 

Visão geral da arquitetura de rede 

      A camada Network Equipment consiste essencialmente em estações base responsáveis pelo recebimento das mensagens enviadas pelos dispositivos e envio das mesmas para a camada Sigfox Support Systems. A camada Sigfox Support System constitui a rede principal sendo encarregada de processar as mensagens e enviá-las através de callbacks para o sistema do cliente.  A camada Sigfox Support System inclui módulos e recursos que são essenciais para garantir a implantação, operação e o monitoramento da rede, como o sistema de suporte empresarial para pedidos e cobranças, e suporte de rádio para garantir o bom funcionamento da rede. A comunicação entre as camadas é feita através da Internet por uma conexão VPN. 

Arquitetura de rede plana 

    A arquitetura plana da rede Sigfox é a chave para reduzir os custos de investimentos e operacional. O Software Defined Radio (SDR) Sigfox ajuda a reduzir os custos das estações base e a aumentar sua flexibilidade. Nesta arquitetura a operadora Sigfox – no Brasil a WND – entrega aos seus parceiros as camadas de rede intermediárias prontas para uso. Cabe ao desenvolvedor a criação da aplicação na nuvem e a escolha ou criação dos dispositivos que pretende usar. Não há necessidade de se preocupar com a compra de gateways, sua instalação e manutenção planejamento de RF, contratação e estabelecimento de backhaul, criação de um servidor para receber mensagens em tempo real, etc. 

Figura 5 – Arquitetura plana 

Alta capacidade de rede 

    A rede Sigfox possui uma alta capacidade de rede permitindo a escala de bilhões de objetos conectados. Essa capacidade de rede são resultados dos seguintes fatores: 

A modulação ultra-narrow band tem o benefício de eficiência no espectro e resistente a interferências, enquanto toda a energia é concentrada em uma largura banda muito pequena; 

Diversidade de tempo e frequência, introduzida pelo acesso aleatório; 

Diversidade espacial devido às células de rede sobrepostas. 

Figura 6 – Combinação de especificações Sigfox resulta em uma alta capacidade da rede 

Outra vantagem é que a capacidade é a mesma independentemente do link de rádio, enquanto outras redes têm uma capacidade decrescente à medida que a qualidade do link de rádio piora: 

Figura 7 – Capacidade de manutenção independentemente da qualidade do link de rádio 

Alta eficiência energética 

            A alta eficiência energética permitida pela tecnologia Sigfox permite que os parceiros produzam chips que consomem de 10 mA a 50 mA durante a transmissão. Esse valor vai depender do chip utilizado. A figura a seguir exibe o consumo em durante a comunicação e tempo inativo: 

Figura 8 – Baixíssimo consumo aumenta o tempo de bateria (região FCC) 

Longo alcance 

Uma das principais vantagens competitivas da tecnologia Sigfox está na grande cobertura possível e com um número relativamente pequeno de estações base. Esta vantagem deriva de: 

O “link budget” muito bom da tecnologia Sigfox. Ele indica quanto o sinal pode ser atenuado e ainda assim se ter uma recepção perfeita. Na tecnologia Sigfox o link budget é de 158dB, da mesma ordem de LTE e NB-IOT; 

A Taxa de dados propositalmente limitada a menos que 600bps aumenta a sensibilidade do receptor e a chance de uma recepção adequada; boa cobertura indoor, devido ao uso de banda sub-GHz. 

Figura 9 – Link Budget Sigfox (região FCC) 

Resiliência a interferências 

     â€¯A tecnologia Sigfox apresenta capacidades anti-jamming únicas, devido à robustez intrínseca da UNB, juntamente com a diversidade espacial das estações de base (+20 dB). A melhor prova da alta resiliência aos interferentes é a capacidade de transmitir apesar da presença de sinais de interferência. A modulação de banda ultra-estreita tem uma certa robustez intrínseca porque a sobreposição com o ruído é muito baixa. Para que uma mensagem seja recebida, o sinal deve ser pelo menos 8 dB acima do nível de ruído, conforme exibido na figura a seguir: 

Figura 10 – Capacidades anti-jamming provida pela UNB 

Segurança 

      Com base em sua experiência e suas parcerias, a Sigfox aplicou a segurança por princípios de design em todas as etapas de definição do seu protocolo e no desenvolvimento de sua infra-estrutura. Isso abrange a cadeia IoT completa, incluindo dispositivos, infraestrutura de rede e serviços baseados na nuvem: 

Figura 11 – Segurança por padrão 

Referências Bibliográficas 

EMBARCADOS. Uma visão técnica da Rede SigFox. Disponível em: https://www.embarcados.com.br/uma-visão-tecnica-da-rede-sigfox/. Acesso em: 15 jun. 2022. 

SIGFOX. Nossa História. Disponível em: https://www.sigfox.com/en/sigfox-story. Acesso em: 15 jun. 2022. 

[ID:113] Autor:Lucas Henrique da Cunha - Criado em: 2022-06-28 22:22:57 - [ Compartilhar ]

Introdução

O monitoramento da qualidade de líquidos é um procedimento de extrema importância em indústrias, ou até mesmo em nossas casas. O projeto em questão visa realizar o monitoramento remoto de um recipiente controlado, medindo os valores de PPM(partículas por milhão) presentes e o nível de líquido utilizando sensores apropriados.

   Para realizar as medições foi utilizado um sensor de nível de água analógico para o monitoramento no nível da água e um sensor TDS para as medições de condutividade da água.

  O Sensor Módulo Medidor de Qualidade da Água TDS, tem a função de realizar as medições das impurezas encontradas na água. Segundo Ramalho (2009) a condutividade é definida como a capacidade de um material em conduzir corrente elétrica, sendo assim a capacidade de condução depende da presença de íons. 

 Este projeto tem em vista a montagem de um sistema de observação da qualidade da água armazenada em um reservatório, disponibilizando os dados na internet de forma acessível.

Metodologia

O servidor para a hospedagem e o banco de dados do servidor foi utilizado o servidor do AWS da amazon, através dos serviços do DuckDNS para a configuração do site.

Para a configuração do servidor e a instalação dos programas necessários, foi utilizado o programa do Windows Visual estúdio. Por meio dele houve a instalação e configuração do PHP, APACHE, Mysql, NodeRed.

A programação foi aplicada no microcontrolador por meio do programa Arduino configurando para o envio dos dados obtidos pelos sensores e os envia para o banco de dados.

Os dados obtidos são processados através do NodeRed que coleta os dados e os envia para a apresentação no layout do site.

O protótipo finalizado contará com o tanque para armazenagem da água, o recipiente terá duas válvulas, com intuito de abastecimento e drenagem.

Para a montagem do site foi utilizado do servidor AWS da amazon para a criação do servidor e o banco de dados para o armazenamento de dados.

O controle do sistema será realizado por uma malha fechada, que de acordo com Maya e Leonardi (2014) é caracterizado por um sistema de controle que impõe as condições das saídas de acordo com as variáveis de entrada. As variáveis de entrada do sistema são dadas pelo medidor de condutividade da água (TDS) e pelo sensor de nível da água.

Os dados obtidos serão processados através de um microcontrolador modelo ESP 32. O componente será programado para manter a água em um nível de turbidez aceitável, iniciando um processo de drenagem, até o esvaziamento completo do recipiente.

Resultados e Discussões

Tendo uma bancada de teste pronta juntamente a programação e o banco de dados, foram analisadas as amostras de água dentro de um reservatório com duas válvulas, entrada e saída, junto a um sensor de condutividade TDS. 

Seus dados foram enviados para um banco de dados de um website web utilizando Node-RED e MQTT, mostrando os valores em um layout criado.

Conclusão

Tendo os conhecimentos da importância do uso cotidiano da água. Obteve-se um projeto que alcança as demandas de analisar a condutividade da água armazenada, assim comparando o nível de TDS para relatar se ela é própria de acordo com esse processo, de forma remota com o banco de dados online.

[ID:112] Autor:Danilo Schiavi Junior - Criado em: 2022-06-28 16:43:59 - [ Compartilhar ]

Definição

               A SigFox foi desenvolvida por uma empresa francesa, que leva o mesmo nome, com o intuito de conectar todos os objetos do mundo físico ao universo digital. A SigFox trata-se de uma rede global dedicada à Internet das Coisas (IoT), baseada em baixo consumo de energia, longo alcance e dados que oferecem um serviço de conectividade de ponta a ponta.

Princípios da tecnologia

Ultra-Narrow Band (UNB):

                    A rede Sigfox usa a técnica de Ultra-Narrow Band para a transmissão de mensagens. Esta técnica usa canais de 100Hz de largura de banda nas regiões ETSI e ARIB (Europa, Japão), e de 600Hz na região FCC (Américas, Oceania).

Figura 1 – A rede Sigfox é baseada em Ultra-Narrow Banda

  A tecnologia Ultra Narrow Band se caracteriza por um uso ótimo da potência disponível, o que permite que os dispositivos Sigfox se comuniquem por longas distâncias de forma confiável, mesmo em canais com interferências e ruídos.

         A faixa de frequência utilizada depende da região. Na Europa, por exemplo, é usada a faixa entre 868 e 868,2 MHz. Já no resto do mundo é usada a faixa entre 902 e 928 MHz, havendo restrições de acordo com a regulamentação local.

Acesso Aletório ao Canal / Diversidade 

      O acesso aleatório é um recurso fundamental para alcançar uma alta qualidade de serviço, a transmissão não está sincronizada entre a rede e o dispositivo. O dispositivo envia a mensagem em uma frequência aleatória e em seguida envia 2 réplicas em diferentes frequências e tempo, criando diversidade de tempo e frequência.  Esta diversidade aumenta muito a resistência do sistema a interferências pois uma mesma mensagem tenta vários “caminhos” – frequências e tempos diferentes para garantir a recepção bem-sucedida da mensagem.

Figura 2 –  Salto de frequência nas repetições (ETSI)

Recepção cooperativa

      Na recepção cooperativa um objeto não está vinculado a uma estação base específica, ao contrário dos protocolos celulares. A mensagem emitida é recebida por uma estação base próxima e, em média, o número de estações base é de 3. Isso é chamado de “diversidade espacial”. Diversidade espacial, juntamente com a diversidade de tempo e frequência das repetições, são os principais fatores por trás da alta qualidade de serviço da rede Sigfox.

Figura 3 – Mensagem recebida por múltiplas estações base Sigfox

Mensagens Pequenas

             Para atender as restrições de autonomia de bateria e custo dos objetos conectados,  o protocolo  Sigfox é otimizado para mensagens pequenas. O tamanho da mensagem vai de 0 a 12 bytes. Embora a princípio isto pareça pouco, com uma mensagem de até 12 bytes é o suficiente para a maioria das aplicações de IoT para objetos simples. Com 132 Bytes é possível enviar informações de sensores, eventos, coordenadas de GPS e dados da aplicação. 

Tabela 1 – Exemplos de mensagens

Principais características da rede Sigfox

Visão geral da arquitetura de rede:

A rede Sigfox possui uma arquitetura horizontal e estreita, composta por 2 camadas principais:

Figura 4 – Arquitetura da rede Sigfox

Visão geral da arquitetura de rede

      A camada Network Equipment consiste essencialmente em estações base responsáveis pelo recebimento das mensagens enviadas pelos dispositivos e envio das mesmas para a camada Sigfox Support Systems. A camada Sigfox Support System constitui a rede principal sendo encarregada de processar as mensagens e enviá-las através de callbacks para o sistema do cliente.  A camada Sigfox Support System inclui módulos e recursos que são essenciais para garantir a implantação, operação e o monitoramento da rede, como o sistema de suporte empresarial para pedidos e cobranças, e suporte de rádio para garantir o bom funcionamento da rede. A comunicação entre as camadas é feita através da Internet por uma conexão VPN.

Arquitetura de rede plana

    A arquitetura plana da rede Sigfox é a chave para reduzir os custos de investimentos e operacional. O Software Defined Radio (SDR) Sigfox ajuda a reduzir os custos das estações base e a aumentar sua flexibilidade. Nesta arquitetura a operadora Sigfox – no Brasil a WND – entrega aos seus parceiros as camadas de rede intermediárias prontas para uso. Cabe ao desenvolvedor a criação da aplicação na nuvem e a escolha ou criação dos dispositivos que pretende usar. Não há necessidade de se preocupar com a compra de gateways, sua instalação e manutenção planejamento de RF, contratação e estabelecimento de backhaul, criação de um servidor para receber mensagens em tempo real, etc.

Figura 5 – Arquitetura plana

Alta capacidade de rede

    A rede Sigfox possui uma alta capacidade de rede permitindo a escala de bilhões de objetos conectados. Essa capacidade de rede são resultados dos seguintes fatores:

•A modulação ultra-narrow band tem o benefício de eficiência no espectro e resistente a interferências, enquanto toda a energia é concentrada em uma largura banda muito pequena;

•Diversidade de tempo e frequência, introduzida pelo acesso aleatório;

•Diversidade espacial devido às células de rede sobrepostas.

Figura 6 – Combinação de especificações Sigfox resulta em uma alta capacidade da rede

  Outra vantagem é que a capacidade é a mesma independentemente do link de rádio, enquanto outras redes têm uma capacidade decrescente à medida que a qualidade do link de rádio piora:

Figura 7  – Capacidade de manutenção independentemente da qualidade do link de rádio

Alta eficiência energética

            A alta eficiência energética permitida pela tecnologia Sigfox permite que os parceiros produzam chips que consomem de 10 mA a 50 mA durante a transmissão. Esse valor vai depender do chip utilizado. A figura a seguir exibe o consumo em durante a comunicação e tempo inativo:

Figura 8 – Baixíssimo consumo aumenta o tempo de bateria (região FCC)

Longo alcance

        Uma das principais vantagens competitivas da tecnologia Sigfox está na grande cobertura possível e com um número relativamente pequeno de estações base. Esta vantagem deriva de:

•O “link budget” muito bom da tecnologia Sigfox. Ele indica quanto o sinal pode ser atenuado e ainda assim se ter uma recepção perfeita. Na tecnologia Sigfox o link budget é de 158dB, da mesma ordem de LTE e NB-IOT;

•A Taxa de dados propositalmente limitada a menos que 600bps aumenta a sensibilidade do receptor e a chance de uma recepção adequada; boa cobertura indoor, devido ao uso de banda sub-GHz.

Figura 9 – Link Budget Sigfox (região FCC)

Resiliência a interferências

           A tecnologia Sigfox apresenta capacidades anti-jamming únicas, devido à robustez intrínseca da UNB, juntamente com a diversidade espacial das estações de base (+20 dB). A melhor prova da alta resiliência aos interferentes é a capacidade de transmitir apesar da presença de sinais de interferência. A modulação de banda ultra-estreita tem uma certa robustez intrínseca porque a sobreposição com o ruído é muito baixa. Para que uma mensagem seja recebida, o sinal deve ser pelo menos 8 dB acima do nível de ruído, conforme exibido na figura a seguir:

Figura 10 – Capacidades anti-jamming provida pela UNB

Segurança

         Com base em sua experiência e suas parcerias, a Sigfox aplicou a segurança por princípios de design em todas as etapas de definição do seu protocolo e no desenvolvimento de sua infra-estrutura. Isso abrange a cadeia IoT completa, incluindo dispositivos, infraestrutura de rede e serviços baseados na nuvem:

Referências Bibliográficas

EMBARCADOS. Uma visão técnica da Rede SigFox. Disponível em: https://www.embarcados.com.br/uma-visão-tecnica-da-rede-sigfox/. Acesso em: 15 jun. 2022.

SIGFOX. Nossa História. Disponível em: https://www.sigfox.com/en/sigfox-story. Acesso em: 15 jun. 2022.

[ID:111] Autor:Danilo Schiavi Junior - Criado em: 2022-06-28 16:22:53 - [ Compartilhar ]

O que é UDP?

Como todos os protocolos de rede, o UDP é um método padronizado para transferir dados entre dois computadores em uma rede. Comparado a outros protocolos, o UDP realiza este processo de forma simples: envia pacotes (unidades de transmissão de dados) diretamente para um computador de destino sem estabelecer primeiro uma conexão, indicando a ordem dos referidos pacotes ou verificando se eles chegaram como pretendido — Os pacotes UDP são chamados de ‘datagramas’.

Para que o UDP é usado?

O UDP é comumente usado em comunicações sensíveis ao tempo, em que, ocasionalmente, descartar pacotes é melhor do que esperar. O tráfego de voz e vídeo é enviado usando este protocolo porque ambos são sensíveis ao tempo e projetados para lidar com algum nível de perda. Por exemplo, VOIP (voz sobre IP), que é usado por muitos serviços telefônicos baseados na Internet, opera sobre UDP. Isso ocorre porque uma conversa telefônica estática é preferível a uma que seja nítida, mas muito atrasada.

Entenda a estrutura de cabeçalho UDP!

UDP envolve datagramas com um cabeçalho UDP, que contém quatro campos totalizando oito bytes.

Os campos em um cabeçalho UDP são:

• Porta de origem  – a porta do dispositivo que envia os dados. Este campo pode ser definido como zero se o computador de destino não precisar responder ao remetente.
• Porta de destino  – a porta do dispositivo que recebe os dados. Os números da porta UDP podem estar entre 0 e 65.535.
• Comprimento  – especifica o número de bytes compreendendo o cabeçalho UDP e os dados de carga útil UDP. O limite para o campo de comprimento UDP é determinado pelo protocolo IP subjacente usado para transmitir os dados.
• Checksum  – O checksum permite que o dispositivo receptor verifique a integridade do cabeçalho do pacote e da carga útil. É opcional no IPv4, mas tornou-se obrigatório no IPv6

https://lh4.googleusercontent.com/3NwFlsMVmQiISYXX0JqTddeYO_wnIsb_nZOC3EjfanXVHagYspjt2BtvtiqYgka8RTDaUNGsWGOCZMHmCuBRKzuv6P587zQwtnshGcGMUeFbeNPORt_jgO5OBuZVH7er1zk9zqrq=s0

TCP vs UDP: quais as principais diferenças entre esses protocolos?

O UDP é mais rápido, mas menos confiável do que o TCP, outro protocolo de transporte comum. Em uma comunicação TCP, os dois computadores começam estabelecendo uma conexão por meio de um processo automatizado denominado ‘handshake’. Somente depois que esse handshake for concluído, um computador realmente transferirá pacotes de dados para o outro.

As comunicações UDP não passam por esse processo. Em vez disso, um computador pode simplesmente começar a enviar dados para o outro:

Além disso, as comunicações TCP indicam a ordem em que os pacotes de dados devem ser recebidos e confirmam se os pacotes chegam conforme o planejado. Se um pacote não chegar — por exemplo, devido a congestionamento em redes intermediárias — o TCP exige que ele seja reenviado. As comunicações UDP não incluem nenhuma dessas funcionalidades.

Quais as vantagens e desvantagens do UDP?

O UDP tem vários benefícios para diferentes tipos de aplicativos, incluindo:

• Sem atrasos de retransmissão  — UDP é adequado para aplicativos sensíveis ao tempo que não podem pagar atrasos de retransmissão para pacotes perdidos. Os exemplos incluem Voice over IP (VoIP), jogos online e streaming de mídia.
• Velocidade  — a velocidade do UDP o torna útil para protocolos de resposta a consultas, como DNS, nos quais os pacotes de dados são pequenos e transacionais.
• Adequado para broadcasts  — a falta de comunicação ponta a ponta do UDP o torna adequado para broadcasts, em que os pacotes de dados transmitidos são endereçados como recebíveis por todos os dispositivos na Internet. As transmissões UDP podem ser recebidas por um grande número de clientes sem sobrecarga do lado do servidor.
•  
•  
•  
• Desvantagens do protocolo de datagrama do usuário
•  1. Sem conexão

UDP é sem conexão, o que significa que não requer necessariamente um circuito virtual antes do processo de transferência de dados. Portanto, sem qualquer preparação ou negociação, o grama de dados pode ser enviado ao receptor. O receptor deve ser capaz de cuidar deles.

2. Não confiável

UDP geralmente não é confiável porque não há nenhum conceito de retransmissão, reconhecimento ou tempo limite aqui. Sempre que um grama de dados é enviado, não é possível garantir que será entregue ao host de destino. Às vezes, o grama de dados pode ser perdido no caminho ou entregue duas vezes. A pior parte é que não há sequer uma indicação disso, a menos que o anfitrião decida mencioná-los. No entanto, esses tipos de taxas de falha são muito baixas em conexões de rede.

3. Pedido incorreto

Além de os dados não serem entregues, também podem estar fora de serviço no UDP. Não é possível garantir que a sequência em que os dados estão sendo enviados esteja na mesma ordem ao chegar ao aplicativo host. Às vezes, os pacotes podem ser ordenados de forma que você receba primeiro um pacote que foi enviado com atraso. Além disso, não há como prever esses pedidos até que sejam recebidos.

4. Sem controle de congestionamento

Ao contrário do TCP, os métodos de controle de congestionamento não estão presentes no UDP. Como não há nenhum método de controle de congestionamento no UDP, um grande número de dados transmitidos via UDP pode causar congestionamentos. Para isso, não há restrições que possam ser impostas.

5. Suporte para roteador

No que diz respeito ao tratamento do UDP, os roteadores são bastante descuidados. Isso ocorre porque sempre que um grama de dados é colidido, ele não os retransmite. Além disso, em um roteador os pacotes UDP serão descartados antes mesmo dos pacotes TCP.

Referencia: 

SEABRA, Giulianna. O que é UDP e quais as diferenças com o TCP?. In: O que é UDP e quais as diferenças com o TCP?. [S. l.], 19 jun. 2019. Disponível em: https://blog.betrybe.com/desenvolvimento-web/udp-diferencas-tcp/. Acesso em: 23 jun. 2022.

[ID:110] Autor:Arthur Braga Zerondi - Criado em: 2022-06-28 10:49:29 - [ Compartilhar ]

Definição

Ultra-Narrow Band (UNB):

                    A rede Sigfox usa a técnica de Ultra-Narrow Band para a transmissão de mensagens. Esta técnica usa canais de 100Hz de largura de banda nas regiões ETSI e ARIB (Europa, Japão), e de 600Hz na região FCC (Américas, Oceania).

Figura 1 – A rede Sigfox é baseada em Ultra-Narrow Band

           A tecnologia Ultra Narrow Band se caracteriza por um uso ótimo da potência disponível, o que permite que os dispositivos Sigfox se comuniquem por longas distâncias de forma confiável, mesmo em canais com interferências e ruídos.

         A faixa de frequência utilizada depende da região. Na Europa, por exemplo, é usada a faixa entre 868 e 868,2 MHz. Já no resto do mundo é usada a faixa entre 902 e 928 MHz, havendo restrições de acordo com a regulamentação local.

 

Acesso Aletório ao Canal / Diversidade 

      O acesso aleatório é um recurso fundamental para alcançar uma alta qualidade de serviço, a transmissão não está sincronizada entre a rede e o dispositivo. O dispositivo envia a mensagem em uma frequência aleatória e em seguida envia 2 réplicas em diferentes frequências e tempo, criando diversidade de tempo e frequência.  Esta diversidade aumenta muito a resistência do sistema a interferências pois uma mesma mensagem tenta vários “caminhos” – frequências e tempos diferentes para garantir a recepção bem-sucedida da mensagem.

Figura 2 –  Salto de frequência nas repetições (ETSI)

 

Recepção cooperativa

      Na recepção cooperativa um objeto não está vinculado a uma estação base específica, ao contrário dos protocolos celulares. A mensagem emitida é recebida por uma estação base próxima e, em média, o número de estações base é de 3. Isso é chamado de “diversidade espacial”. Diversidade espacial, juntamente com a diversidade de tempo e frequência das repetições, são os principais fatores por trás da alta qualidade de serviço da rede Sigfox.

Figura 3 – Mensagem recebida por múltiplas estações base Sigfox

Mensagens Pequenas

             Para atender as restrições de autonomia de bateria e custo dos objetos conectados,  o protocolo  Sigfox é otimizado para mensagens pequenas. O tamanho da mensagem vai de 0 a 12 bytes. Embora a princípio isto pareça pouco, com uma mensagem de até 12 bytes é o suficiente para a maioria das aplicações de IoT para objetos simples. Com 132 Bytes é possível enviar informações de sensores, eventos, coordenadas de GPS e dados da aplicação. 

Tabela 1 – Exemplos de mensagens

 

 

Mensagem	Tamanho da mensagem
Coodenada GPS	6 byte complete, muito menos se delta da última posição completa
Temperatura	10 bits (de -40 a +105 com 0,1C de precisão)
Velocidade	1 byte - 0 a 255Km/h
Stats do Objeto	1 bit
Keep Alive	0 bytes

 

Principais características da rede Sigfox

Visão geral da arquitetura de rede:

A rede Sigfox possui uma arquitetura horizontal e estreita, composta por 2 camadas principais:

Figura 4 – Arquitetura da rede Sigfox

Visão geral da arquitetura de rede

      A camada Network Equipment consiste essencialmente em estações base responsáveis pelo recebimento das mensagens enviadas pelos dispositivos e envio das mesmas para a camada Sigfox Support Systems. A camada Sigfox Support System constitui a rede principal sendo encarregada de processar as mensagens e enviá-las através de callbacks para o sistema do cliente.  A camada Sigfox Support System inclui módulos e recursos que são essenciais para garantir a implantação, operação e o monitoramento da rede, como o sistema de suporte empresarial para pedidos e cobranças, e suporte de rádio para garantir o bom funcionamento da rede. A comunicação entre as camadas é feita através da Internet por uma conexão VPN.

Arquitetura de rede plana

    A arquitetura plana da rede Sigfox é a chave para reduzir os custos de investimentos e operacional. O Software Defined Radio (SDR) Sigfox ajuda a reduzir os custos das estações base e a aumentar sua flexibilidade. Nesta arquitetura a operadora Sigfox – no Brasil a WND – entrega aos seus parceiros as camadas de rede intermediárias prontas para uso. Cabe ao desenvolvedor a criação da aplicação na nuvem e a escolha ou criação dos dispositivos que pretende usar. Não há necessidade de se preocupar com a compra de gateways, sua instalação e manutenção planejamento de RF, contratação e estabelecimento de backhaul, criação de um servidor para receber mensagens em tempo real, etc.

Figura 5 – Arquitetura plana

Alta capacidade de rede

    A rede Sigfox possui uma alta capacidade de rede permitindo a escala de bilhões de objetos conectados. Essa capacidade de rede são resultados dos seguintes fatores:

•A modulação ultra-narrow band tem o benefício de eficiência no espectro e resistente a interferências, enquanto toda a energia é concentrada em uma largura banda muito pequena;

•Diversidade de tempo e frequência, introduzida pelo acesso aleatório;

•Diversidade espacial devido às células de rede sobrepostas.

Figura 6 – Combinação de especificações Sigfox resulta em uma alta capacidade da rede

      Outra vantagem é que a capacidade é a mesma independentemente do link de rádio, enquanto outras redes têm uma capacidade decrescente à medida que a qualidade do link de rádio piora:

Figura 7  – Capacidade de manutenção independentemente da qualidade do link de rádio

Alta eficiência energética

            A alta eficiência energética permitida pela tecnologia Sigfox permite que os parceiros produzam chips que consomem de 10 mA a 50 mA durante a transmissão. Esse valor vai depender do chip utilizado. A figura a seguir exibe o consumo em durante a comunicação e tempo inativo:

Figura 8 – Baixíssimo consumo aumenta o tempo de bateria (região FCC)

Longo alcance

 

        Uma das principais vantagens competitivas da tecnologia Sigfox está na grande cobertura possível e com um número relativamente pequeno de estações base. Esta vantagem deriva de:

•O “link budget” muito bom da tecnologia Sigfox. Ele indica quanto o sinal pode ser atenuado e ainda assim se ter uma recepção perfeita. Na tecnologia Sigfox o link budget é de 158dB, da mesma ordem de LTE e NB-IOT;

•A Taxa de dados propositalmente limitada a menos que 600bps aumenta a sensibilidade do receptor e a chance de uma recepção adequada; boa cobertura indoor, devido ao uso de banda sub-GHz.

Figura 9 – Link Budget Sigfox (região FCC)

Resiliência a interferências

           A tecnologia Sigfox apresenta capacidades anti-jamming únicas, devido à robustez intrínseca da UNB, juntamente com a diversidade espacial das estações de base (+20 dB). A melhor prova da alta resiliência aos interferentes é a capacidade de transmitir apesar da presença de sinais de interferência. A modulação de banda ultra-estreita tem uma certa robustez intrínseca porque a sobreposição com o ruído é muito baixa. Para que uma mensagem seja recebida, o sinal deve ser pelo menos 8 dB acima do nível de ruído, conforme exibido na figura a seguir:

Figura 10 – Capacidades anti-jamming provida pela UNB

Segurança

         Com base em sua experiência e suas parcerias, a Sigfox aplicou a segurança por princípios de design em todas as etapas de definição do seu protocolo e no desenvolvimento de sua infra-estrutura. Isso abrange a cadeia IoT completa, incluindo dispositivos, infraestrutura de rede e serviços baseados na nuvem:

Figura 11 – Segurança por padrão

Referências Bibliográficas

EMBARCADOS. Uma visão técnica da Rede SigFox. Disponível em: https://www.embarcados.com.br/uma-visão-tecnica-da-rede-sigfox/. Acesso em: 15 jun. 2022.

SIGFOX. Nossa História. Disponível em: https://www.sigfox.com/en/sigfox-story. Acesso em: 15 jun. 2022.

[ID:109] Autor:Pietra Bessani Soares - Criado em: 2022-06-27 22:11:54 - [ Compartilhar ]

O que é o NB-IoT?

O Narrowband Internet of Things (NB-IoT) que na tradução quer dizer Banda Estreita para Internet das Coisas é um padrão de tecnologia de conectividade sem fio criado pelo 3GPP (3rd Generation Partnership Project). Desenvolvido para oferecer uma boa conectividade, cabe a ele realizar a cobertura de grandes áreas, mas que não demandam um alto volume de transmissão de dados como é o caso das lavouras do agro. 

Assim, o NB-IoT é conceituado como um padrão de tecnologia LPWAN (Low Power Wide Area Network) que permite uma ampla conexão de dispositivos e serviços, por imeio das redes móveis, como as redes 3G e 4G.  Ele usa um espectro de frequência licenciado onde não há interferências com outros dispositivos, garantindo assim uma transferência de dados bem mais estáveis.

Com base nisso, ele foi projetado para que se pudesse trabalhar com dispositivos específicos que apresentavam algumas limitações: como poder de processamento, a vida útil da bateria e longas áreas.

Figura 1 - NB-IoT

Fonte: Enterprise IoT Insights (2019)

Funcionamento

O NB-IoT foi desenvolvido para operar usando bandas de espectro estreito de 180kHz ou 200kHz. Ele é resumidamente uma tecnologia de celular, ou seja, usa as bandas de celulares de comunicação, sendo projetado para operar de 3 maneiras diferentes:

- Usando a banda GSM para substituir implantações existentes (autônomo);

- Usando a banda LTE enquanto a compartilha (dentro da banda);

- Usando espaçamento entre os canais LTE para maximizar o espectro de comunicação (banda de guarda).

Uma vez que a conexão é estabelecida, o dispositivo mantém a conexão por um tempo configurável até que se torne nativo e se desconecta.

Funcionamento dos Dispositivos Habilitados para o NB-IoT

O dispositivo permanece desconectado da rede até que tenha dados para transmitir, então ele estabelece uma conexão com o NB-IoT, transmite os dados e desconecta. Quando conectado, o equipamento do usuário pode solicitar mais recursos e transmitir mais dados.

O NB-Iot também permite uma desconexão imediata logo que a confirmação dos dados é recebida.

Um exemplo de dispositivo é o Quectel BC95-G, que é um módulo NB-IoT certificado pela Telefônica (VIVO) de alto desempenho que suporta várias bandas de frequência.

Figura 2 - Módulo Quectel BC95-G

Fonte: Quectel

Vantagens

Algumas de suas vantagens são:

- Tecnologia de baixo custo;

- Funciona com um baixo consumo energético;

- Maior longevidade das baterias dos equipamentos;

- Permite a conexão de um númerosignificativo de equipamentos IoT;

- Cobertura de longo alcance, sendo por isso ideal para áreas agrícolas.

Desvantagens

Algumas das suas desvantagens são:

- Deve ser usado para enviar e receber pequenas quantidades de dados;

- Não é um protocolo de comunicação baseado em IP e por isso não pode ser utilizado em aplicações como de um smartphone comum;

- Indicada para ativos basicamente estáticos, como medidores ou sensores fixos em um local, já que os handoffs de rede e torre podem ser um problema.

Aplicações

Dentre suas aplicações estão:

- Transmitir dados e informações de sensores de temperatura, umidade e qualidade do ar/solo de forma eficaz e segura;

- Transmitir dados do monitoramento das variáveis internas de silos armazenadores de grãos;

- Georreferenciamento.

Referências

BLACKMAN, J. Três modelos de implantação de NB-IoT – e por que o desempenho de NB-IoT não é o que deveria ser. Enterprise IoT Insights, 2019. Disponível em: https://enterpriseiotinsights.com/20190718/channels/fundamentals/three-nb-iot-deployment-models. Acessado em: 21 jun. 2022.

BLOG CONECTARAGRO. NB-IoT: Veja como funciona e quais as suas características. 2021. Disponível em: https://blog.conectaragro.com.br/como-funciona-e-caracteristicas-do-nb-iot/. Acessado em: 21 jun. 2022.

BLOG CONECTARAGRO. NB-IoT: 4 recursos que você pode utilizar na sua lavoura. 2021. Disponível em: https://blog.conectaragro.com.br/nb-iot-4-recursos-que-voce-pode-utilizar/. Acessado em: 21 jun. 2022.

ENTERPRISE IOT INSIGHTS. Three NB-IoT deployment models – and why NB-IoT performance is not what it should be. 2019. Disponível em: https://enterpriseiotinsights.com/20190718/channels/fundamentals/three-nb-iot-deployment-models. Acessado em: 21 Jun. 2022.

NBIoT: Going where 2G, 3G, 4G can’t go. Realty & More Magazine. Disponível em: https://www.realtynmore.com/nbiot-going-where-2g-3g-4g-cant-go/. Acessado em: 21 Jun. 2022.

QUECTEL. Telefónica Certifies Quectel’s NB-IoT Module with Subscription Swap Capabilities. Disponível em: https://www.quectel.com/news-and-pr/telefonica-certifies-quectels-nb-iot-module-with-subscription-swap-capabilities. Acessado em: 27 Jun. 2022.

[ID:108] Autor:Beatriz Miano Paulino - Criado em: 2022-06-27 21:59:49 - [ Compartilhar ]

Definição

O CoAP, “Constrained Application Protocol”, ou, em uma tradução aproximada, “Protocolo de Aplicação Restrita”, foi desenvolvido pelo grupo de trabalho CoRE (Constrained Restful Environments) do IETF (SILVA; CARVALHO; NAZARIO, 2012).

O CoAP é um protocolo de transferência de informações da camada de aplicação baseado no método request-response, com o mesmo conjunto de operações básicas se comparado ao HTTP (GET, PUT, POST e DELETE), porém consideravelmente mais simples, consome menos memória, processamento e, consequentemente, energia (BORMANN; CASTELLANI; SHELBY, 2012).

O principal responsável pela redução da complexidade é o uso do UDP ao invés do TCP. O CoAP, diferentemente do UDP que não soluciona este problema, trata a perda de pacotes adicionando uma camada à mensagem para detecção e retransmissão dos pacotes. Por esse motivo, um cabeçalho CoAP tem apenas quatro bytes somados a dois bytes para opções e a resposta da requisição ocupa apenas um byte. Assim, uma requisição geralmente usa de 10 a 20 bytes (WESTPHALL, 2018).

A implementação do CoAP não se atém a um protocolo eficiente para a camada de aplicação, mas supera essa ideia viabilizando uma fácil compatibilidade com requisições HTTP através de proxies. Um proxy é um intermediário com um gateway, que com um lado se comunica usando certo protocolo e com outro lado se comunica usando um protocolo diferente, ou seja, é capaz de ligar protocolos diferente e permitir a troca de informações (BORMANN; CASTELLANI; SHELBY, 2012).

Figura 1 - Compatibilidade entre CoAP e HTTP via proxy

Fonte: BORMANN; CASTELLANI; SHELBY, 2012

Aplicação

Ele é bom em ambientes com recursos limitados: dispositivos com energia limitada, enlaces com baixa largura de banda, redes congestionadas ou com perdas. Em redes congestionadas, CoAP/UDP pode funcionar, porém o MQTT/TCP, alternativa ao CoAP, pode não ser nem capaz de administrar um handshake completo. CoAP pode ser usado onde broadcast e multicast são necessários (Comunicação multicast é uma relação de um para vários endpoints. Dispositivos limitados podem ser associados tanto por sua posição ou propósito, e essas relações podem tanto ser pré-configuradas ou configuradas durante as operações. Exemplo: um grupo de interruptores CoAP onde um simples comando de comunicação para o grupo pode acender ou apagar todas as luzes de um andar específico de um prédio). CoAP é adequado na construção de algo no qual um dispositivo é implantado em modo "report only". Uma vez implantado, o dispositivo apenas reporta dados de volta para o servidor. O CoAP é adequado para redes de comunicações domésticas, posto que ferramentas informativas, equipamentos de controle e de comunicação em redes de Casas Inteligentes precisam ser leves e ter baixo custo (SILVA; CARVALHO; NAZARIO, 2012).

Funcionamento

Figura 2 – Camadas abstratas do CoAP

Fonte: SILVA; CARVALHO; NAZARIO, 2012

As aplicações podem fazer requisições ou receber repostas, sendo que estas mensagens são tratadas pelo protocolo de segurança DTLS e enviadas via UDP.

Figura 3 – Cabeçalho CoAP

Fonte: BORMANN, 2014

Segundo Westphall (2018) os componentes do cabeçalho são:

Version: Indica a versão do protocolo usada, para que os dois lados da comunicação saibam qual versão do protocolo seguir. Caso um valor não conhecido esteja nesse campo, a mensagem deve ser ignorada.

Type:

• Confirmable (0): Mensagem enviada deve ser confirmada pelo receptor através de um “Acknowledgement”, para mensagens com confiabilidade. Essa mensagem é retransmitida com intervalos que crescem exponencialmente até o recebimento do “Ack” ou “Reset”.
• Non-Confirmable(1): Mensagem enviada deve não ser confirmada com “Acknowledgement” e rejeitada caso o receptor não seja capaz de entendê-la.
• Acknowledgement (2): Mensagem enviada como primeira resposta de uma mensagem do tipo Confirmable, identificando o ID da mensagem que está sendo confirmada, indicando seu recebimento.
• Reset (3): Indica que uma mensagem (Confirmable ou Non-Confirmable) foi recebida, mas o receptor não pôde processar adequadamente, provavelmente por não conhecer o contexto adequado da mensagem.

Token Lengh: Indica o tamanho do campo Token, na segunda linha do cabeçalho.

Code: Indica o tipo de requisição que está sendo feita, semelhante ao HTTP, o CoAP implementa os métodos básicos GET, POST, PUT e DELETE. Tratando-se de uma resposta, o campo Code indica o código da resposta pertencendo a uma das três classes: sucesso, erro do cliente ou erro do servidor.

Message ID: É um identificador, normalmente sequencial, para cada mensagem enviada por determinado emissor, o qual não deve ser reutilizado até o “Ack” não ser mais esperado pelo emissor da mensagem.

Token: Contendo de 0 a 8 bytes de informação útil, serve para relacionar a requisição à determinada resposta. Idealmente, deve ser implementado de maneira que o token para o par cliente-servidor seja único.

Options: É um campo usado para definir informações como: URI do destinatário da mensagem, porta do destinatário, caminho do recurso, query (em caso de parametrização), formato do payload, formato de conteúdo aceito como resposta, tempo limite para cache, condicionais de formato como resposta e outras.

Payload: O payload de uma mensagem é a representação do recurso requisitado ao servidor, em caso de GET, ou do recurso enviado ao servidor, em caso de POST ou PUT. Exemplificando: se o cliente fizer a requisição na URI "humidade", e o servidor possuir a informação de que a humidade é de 50%, então essa informação será retornada no campo de payload.

Transmissão de Dados Grandes

O UDP ordena os pacotes enviados, ou seja, a ordem é aleatória, então transmissões muito grandes formadas por mais de um pacote seriam desordenadas em situações como, por exemplo, uma atualização de firmware, essa situação não seria aplicada em simples leituras de sensores, mas em casos em que outras funções maiores são requisitadas (WESTPHALL, 2018).

Para resolver esse problema o CoAP possui uma versão com transmissão em blocos. Cada bloco é enviado com um identificador e uma flag informando se ele é o último bloco. Sendo que cada envio é respondido por um ACK, evitando assim as perdas de pacotes (BORMANN, 2016).

Função Observador

Na arquitetura REST, na maioria das vezes que um cliente deseja receber uma informação do servidor essa ação deve ser feita através de um comando GET para cada leitura. Dessa maneira, caso o cliente deseje receber uma informação periodicamente, ele deve enviar um GET nos intervalos de tempo desejado. No entanto, dispositivos com restrições energéticas permanecem hibernando por muito tempo e o momento em que o comando GET é enviado pode coincidir com o momento de hibernação. Além disso, lidar com GETs periodicamente sobrecarrega o dispositivo. Para não haver perdas de requisições, nem sobrecarga de dispositivos, o CoAP tem a Função Observador. Com esta função, o cliente envia um GET, com uma flag indicando o desejo de atualização periódica, ao servidor (sensor, microcontrolador etc.). O sensor, então, dorme sem perder requisições e envia periodicamente o dado especificado no GET (WESTPHALL, 2018).

Segurança

Assim como o HTTP é combinado com o TLS (Transport Layer Security) com objetivo de obter segurança nas trocas de mensagens, o CoAP é combinado com o DTLS (Datagram Transport Layer Security), para obter segurança semelhante à presente na Web. Desse modo em um sistema que utiliza CoAP ela pode estar sem segurança (NoSec), apresentar um par de chaves pré-estabelecido (Pre-shared key (PSKs)), apresentar um par assimétrico de chaves sem certificado (Raw Public Key) ou as chaves assimétricas apresentam um certificado X.509 (SILVA; CARVALHO; NAZARIO, 2012).

Em muitos casos, a maneira mais desejável para garantir segurança entre cliente e servidor seria usando o TLS, todavia o uso do UDP não permite que o TLS seja utilizado, por isso o DTLS (TLS para datagramas) foi projetado para ser o mais similar ao TLS possível, minimizando novas invenções de seguranças e possibilitando aproveitamento de código e estrutura do TLS (RESCORLA, 2012).

Figura 4 – Registro DTLS

Fonte: KOTHMAYR et al., 2013

Segundo Westphall (2018) os componentes do registro são:

Tipo de Conteúdo da Mensagem: Como no TLS, uma mensagem pode representar quatro situações diferentes: estabelecimento do handshake, mudança de protocolos de segurança, alerta de possível comprometimento de segurança ou uma mensagem da aplicação.

Versão do DTLS: Versões diferentes do DTLS possuem diferentes recursos, algoritmos e maneiras de tratar erros. Por isso, no cabeçalho existe o campo para indicar a versão do protocolo entre duas entidades, a fim de haver compatibilidade no uso do DTLS.

Número de sequência: A principal função do número de sequência é a reordenação de mensagens. No DTLS, cada mensagem recebe um número de sequência específico e quando um dispositivo recebe uma mensagem X ele consegue determinar se X é a próxima mensagem esperada. Se for, ela é processada. Se não for, X é direcionada a uma fila para ser processada no momento correto.

Época da mensagem: A época da mensagem é um campo incrementado a cada troca de configurações de segurança (cipher state change) e serve para mensagens serem interpretadas de acordo com as configurações adequadas. Durante a transmissão, os pacotes sofrem alteração de ordem, sendo posteriormente reordenados pelo número de sequência.

Vetor de Inicialização: Cifras de bloco possuem modos de operação como o CBC (Cipher Block Chaining), no qual a saída de um bloco é usado como entrada para cifrar o bloco seguinte. Na cifra do primeiro bloco é usado um vetor de inicialização, geralmente aleatório, necessário para o destinatário decifrar a mensagem.

Payload: O payload é a mensagem em si, que será interpretada pela aplicação após decifração.

MAC: Assim como no TLS, o MAC é calculado para verificação de integridade e autenticidade da mensagem enviada. Todavia, diferentemente do TLS, no DTLS um erro de MAC implica em um alerta e um descarte da mensagem, sem término de conexão. O MAC é calculado com base em uma chave e a concatenação dos campos presentes na Figura 8, considerando o payload em texto claro e excluindo os campos MAC, MAC cont, padding e PL.

CoAP x MQTT

Figura 5 – Comparação CoAP x MQTT

Fonte: ACERVO LIMA, 2021

Referências Bibliográficas

ACERVO LIMA. Diferença entre os protocolos CoAP e MQTT. [S. l.], 2021. Disponível em: https://acervolima.com/diferenca-entre-os-protocolos-coap-e-mqtt/. Acesso em: 14 jun. 2022.

BORMANN, C. The Constrained Application Protocol (CoAP). 2014. Disponível em: https://tools.ietf.org/html/rfc7252. Acesso em: 14 jun. 2022.

BORMANN, C. Block-Wise Transfers in the Constrained Application Protocol (CoAP). 2016. Disponível em: https://tools.ietf.org/html/rfc7959. Acesso em: 14 jun. 2022.

BORMANN, C.; CASTELLANI, A. P.; SHELBY, Z. Coap: An application protocol for billions of tiny internet nodes. IEEE Internet Computing, v. 16, n. 2, p. 62–67, March 2012. ISSN 1089-7801.

KOTHMAYR, T. et al. Dtls based security and two-way authentication for the internet of things. Ad Hoc Networks, v. 11, n. 8, p. 2710 – 2723, 2013. ISSN 1570-8705. Disponível em: http://www.sciencedirect.com/science/article/pii/S1570870513001029. Acesso em: 14 jun. 2022.

RESCORLA, E. Datagram Transport Layer Security Version 1.2. 2012. Disponível em: https://tools.ietf.org/html/rfc6347. Acesso em: 14 jun. 2022.

SILVA, Aryane Barros Maciel; CARVALHO, Felipe Fadul; NAZARIO, Mariana Dabul. Constrained Application Protocol. [S. l.], 2019. Disponível em: https://www.gta.ufrj.br/ensino/eel878/redes1-2019-1/vf/coap/index.html. Acesso em: 14 jun. 2022.

WESTPHALL, Johann. Desenvolvimento de uma Aplicação com dispositivo IoT usando Protocolos DTLS e CoAP. 2018. Trabalho de Conclusão de Curso (Grau de Bacharel em Ciências da Computação) - Universidade Federal de Santa Catarina, [S. l.], 2018. Disponível em: https://repositorio.ufsc.br/bitstream/handle/123456789/192164/Monografia_Johann_Westphall.pdf?sequence=1&isAllowed=y. Acesso em: 14 jun. 2022.

[ID:107] Autor:Leonardo Bonfim Lopes - Criado em: 2022-06-27 16:10:41 - [ Compartilhar ]

Definição

O CoAP, “Constrained Application Protocol”, ou, em uma tradução aproximada, “Protocolo de Aplicação Restrita”, foi desenvolvido pelo grupo de trabalho CoRE (Constrained Restful Environments) do IETF (SILVA; CARVALHO; NAZARIO, 2012).

O CoAP é um protocolo de transferência de informações da camada de aplicação baseado no método request-response, com o mesmo conjunto de operações básicas se comparado ao HTTP (GET, PUT, POST e DELETE), porém consideravelmente mais simples, consome menos memória, processamento e, consequentemente, energia (BORMANN; CASTELLANI; SHELBY, 2012).

O principal responsável pela redução da complexidade é o uso do UDP ao invés do TCP. O CoAP, diferentemente do UDP que não soluciona este problema, trata a perda de pacotes adicionando uma camada à mensagem para detecção e retransmissão dos pacotes. Por esse motivo, um cabeçalho CoAP tem apenas quatro bytes somados a dois bytes para opções e a resposta da requisição ocupa apenas um byte. Assim, uma requisição geralmente usa de 10 a 20 bytes (WESTPHALL, 2018).

A implementação do CoAP não se atém a um protocolo eficiente para a camada de aplicação, mas supera essa ideia viabilizando uma fácil compatibilidade com requisições HTTP através de proxies. Um proxy é um intermediário com um gateway, que com um lado se comunica usando certo protocolo e com outro lado se comunica usando um protocolo diferente, ou seja, é capaz de ligar protocolos diferente e permitir a troca de informações (BORMANN; CASTELLANI; SHELBY, 2012).

Figura 1 - Compatibilidade entre CoAP e HTTP via proxy

Fonte: BORMANN; CASTELLANI; SHELBY, 2012

Aplicação

Ele é bom em ambientes com recursos limitados: dispositivos com energia limitada, enlaces com baixa largura de banda, redes congestionadas ou com perdas. Em redes congestionadas, CoAP/UDP pode funcionar, porém o MQTT/TCP, alternativa ao CoAP, pode não ser nem capaz de administrar um handshake completo. CoAP pode ser usado onde broadcast e multicast são necessários (Comunicação multicast é uma relação de um para vários endpoints. Dispositivos limitados podem ser associados tanto por sua posição ou propósito, e essas relações podem tanto ser pré-configuradas ou configuradas durante as operações. Exemplo: um grupo de interruptores CoAP onde um simples comando de comunicação para o grupo pode acender ou apagar todas as luzes de um andar específico de um prédio). CoAP é adequado na construção de algo no qual um dispositivo é implantado em modo "report only". Uma vez implantado, o dispositivo apenas reporta dados de volta para o servidor. O CoAP é adequado para redes de comunicações domésticas, posto que ferramentas informativas, equipamentos de controle e de comunicação em redes de Casas Inteligentes precisam ser leves e ter baixo custo (SILVA; CARVALHO; NAZARIO, 2012).

Funcionamento

Figura 2 – Camadas abstratas do CoAP

Fonte: SILVA; CARVALHO; NAZARIO, 2012

As aplicações podem fazer requisições ou receber repostas, sendo que estas mensagens são tratadas pelo protocolo de segurança DTLS e enviadas via UDP.

Figura 3 – Cabeçalho CoAP

Fonte: BORMANN, 2014

Segundo Westphall (2018) os componentes do cabeçalho são:

Version: Indica a versão do protocolo usada, para que os dois lados da comunicação saibam qual versão do protocolo seguir. Caso um valor não conhecido esteja nesse campo, a mensagem deve ser ignorada.

Type:

• Confirmable (0): Mensagem enviada deve ser confirmada pelo receptor através de um “Acknowledgement”, para mensagens com confiabilidade. Essa mensagem é retransmitida com intervalos que crescem exponencialmente até o recebimento do “Ack” ou “Reset”.
• Non-Confirmable(1): Mensagem enviada deve não ser confirmada com “Acknowledgement” e rejeitada caso o receptor não seja capaz de entendê-la.
• Acknowledgement (2): Mensagem enviada como primeira resposta de uma mensagem do tipo Confirmable, identificando o ID da mensagem que está sendo confirmada, indicando seu recebimento.
• Reset (3): Indica que uma mensagem (Confirmable ou Non-Confirmable) foi recebida, mas o receptor não pôde processar adequadamente, provavelmente por não conhecer o contexto adequado da mensagem.

Token Lengh: Indica o tamanho do campo Token, na segunda linha do cabeçalho.

Code: Indica o tipo de requisição que está sendo feita, semelhante ao HTTP, o CoAP implementa os métodos básicos GET, POST, PUT e DELETE. Tratando-se de uma resposta, o campo Code indica o código da resposta pertencendo a uma das três classes: sucesso, erro do cliente ou erro do servidor.

Message ID: É um identificador, normalmente sequencial, para cada mensagem enviada por determinado emissor, o qual não deve ser reutilizado até o “Ack” não ser mais esperado pelo emissor da mensagem.

Token: Contendo de 0 a 8 bytes de informação útil, serve para relacionar a requisição à determinada resposta. Idealmente, deve ser implementado de maneira que o token para o par cliente-servidor seja único.

Options: É um campo usado para definir informações como: URI do destinatário da mensagem, porta do destinatário, caminho do recurso, query (em caso de parametrização), formato do payload, formato de conteúdo aceito como resposta, tempo limite para cache, condicionais de formato como resposta e outras.

Payload: O payload de uma mensagem é a representação do recurso requisitado ao servidor, em caso de GET, ou do recurso enviado ao servidor, em caso de POST ou PUT. Exemplificando: se o cliente fizer a requisição na URI "humidade", e o servidor possuir a informação de que a humidade é de 50%, então essa informação será retornada no campo de payload.

Transmissão de Dados Grandes

O UDP ordena os pacotes enviados, ou seja, a ordem é aleatória, então transmissões muito grandes formadas por mais de um pacote seriam desordenadas em situações como, por exemplo, uma atualização de firmware, essa situação não seria aplicada em simples leituras de sensores, mas em casos em que outras funções maiores são requisitadas (WESTPHALL, 2018).

Para resolver esse problema o CoAP possui uma versão com transmissão em blocos. Cada bloco é enviado com um identificador e uma flag informando se ele é o último bloco. Sendo que cada envio é respondido por um ACK, evitando assim as perdas de pacotes (BORMANN, 2016).

Função Observador

Na arquitetura REST, na maioria das vezes que um cliente deseja receber uma informação do servidor essa ação deve ser feita através de um comando GET para cada leitura. Dessa maneira, caso o cliente deseje receber uma informação periodicamente, ele deve enviar um GET nos intervalos de tempo desejado. No entanto, dispositivos com restrições energéticas permanecem hibernando por muito tempo e o momento em que o comando GET é enviado pode coincidir com o momento de hibernação. Além disso, lidar com GETs periodicamente sobrecarrega o dispositivo. Para não haver perdas de requisições, nem sobrecarga de dispositivos, o CoAP tem a Função Observador. Com esta função, o cliente envia um GET, com uma flag indicando o desejo de atualização periódica, ao servidor (sensor, microcontrolador etc.). O sensor, então, dorme sem perder requisições e envia periodicamente o dado especificado no GET (WESTPHALL, 2018).

Segurança

Assim como o HTTP é combinado com o TLS (Transport Layer Security) com objetivo de obter segurança nas trocas de mensagens, o CoAP é combinado com o DTLS (Datagram Transport Layer Security), para obter segurança semelhante à presente na Web. Desse modo em um sistema que utiliza CoAP ela pode estar sem segurança (NoSec), apresentar um par de chaves pré-estabelecido (Pre-shared key (PSKs)), apresentar um par assimétrico de chaves sem certificado (Raw Public Key) ou as chaves assimétricas apresentam um certificado X.509 (SILVA; CARVALHO; NAZARIO, 2012).

Em muitos casos, a maneira mais desejável para garantir segurança entre cliente e servidor seria usando o TLS, todavia o uso do UDP não permite que o TLS seja utilizado, por isso o DTLS (TLS para datagramas) foi projetado para ser o mais similar ao TLS possível, minimizando novas invenções de seguranças e possibilitando aproveitamento de código e estrutura do TLS (RESCORLA, 2012).

Figura 4 – Registro DTLS

Fonte: KOTHMAYR et al., 2013

Segundo Westphall (2018) os componentes do registro são:

Tipo de Conteúdo da Mensagem: Como no TLS, uma mensagem pode representar quatro situações diferentes: estabelecimento do handshake, mudança de protocolos de segurança, alerta de possível comprometimento de segurança ou uma mensagem da aplicação.

Versão do DTLS: Versões diferentes do DTLS possuem diferentes recursos, algoritmos e maneiras de tratar erros. Por isso, no cabeçalho existe o campo para indicar a versão do protocolo entre duas entidades, a fim de haver compatibilidade no uso do DTLS.

Número de sequência: A principal função do número de sequência é a reordenação de mensagens. No DTLS, cada mensagem recebe um número de sequência específico e quando um dispositivo recebe uma mensagem X ele consegue determinar se X é a próxima mensagem esperada. Se for, ela é processada. Se não for, X é direcionada a uma fila para ser processada no momento correto.

Época da mensagem: A época da mensagem é um campo incrementado a cada troca de configurações de segurança (cipher state change) e serve para mensagens serem interpretadas de acordo com as configurações adequadas. Durante a transmissão, os pacotes sofrem alteração de ordem, sendo posteriormente reordenados pelo número de sequência.

Vetor de Inicialização: Cifras de bloco possuem modos de operação como o CBC (Cipher Block Chaining), no qual a saída de um bloco é usado como entrada para cifrar o bloco seguinte. Na cifra do primeiro bloco é usado um vetor de inicialização, geralmente aleatório, necessário para o destinatário decifrar a mensagem.

Payload: O payload é a mensagem em si, que será interpretada pela aplicação após decifração.

MAC: Assim como no TLS, o MAC é calculado para verificação de integridade e autenticidade da mensagem enviada. Todavia, diferentemente do TLS, no DTLS um erro de MAC implica em um alerta e um descarte da mensagem, sem término de conexão. O MAC é calculado com base em uma chave e a concatenação dos campos presentes na Figura 8, considerando o payload em texto claro e excluindo os campos MAC, MAC cont, padding e PL.

CoAP x MQTT

Figura 5 – Comparação CoAP x MQTT

Fonte: ACERVO LIMA, 2021

Referências Bibliográficas

ACERVO LIMA. Diferença entre os protocolos CoAP e MQTT. [S. l.], 2021. Disponível em: https://acervolima.com/diferenca-entre-os-protocolos-coap-e-mqtt/. Acesso em: 14 jun. 2022.

BORMANN, C. The Constrained Application Protocol (CoAP). 2014. Disponível em: https://tools.ietf.org/html/rfc7252. Acesso em: 14 jun. 2022.

BORMANN, C. Block-Wise Transfers in the Constrained Application Protocol (CoAP). 2016. Disponível em: https://tools.ietf.org/html/rfc7959. Acesso em: 14 jun. 2022.

BORMANN, C.; CASTELLANI, A. P.; SHELBY, Z. Coap: An application protocol for billions of tiny internet nodes. IEEE Internet Computing, v. 16, n. 2, p. 62–67, March 2012. ISSN 1089-7801.

KOTHMAYR, T. et al. Dtls based security and two-way authentication for the internet of things. Ad Hoc Networks, v. 11, n. 8, p. 2710 – 2723, 2013. ISSN 1570-8705. Disponível em: http://www.sciencedirect.com/science/article/pii/S1570870513001029. Acesso em: 14 jun. 2022.

RESCORLA, E. Datagram Transport Layer Security Version 1.2. 2012. Disponível em: https://tools.ietf.org/html/rfc6347. Acesso em: 14 jun. 2022.

SILVA, Aryane Barros Maciel; CARVALHO, Felipe Fadul; NAZARIO, Mariana Dabul. Constrained Application Protocol. [S. l.], 2019. Disponível em: https://www.gta.ufrj.br/ensino/eel878/redes1-2019-1/vf/coap/index.html. Acesso em: 14 jun. 2022.

WESTPHALL, Johann. Desenvolvimento de uma Aplicação com dispositivo IoT usando Protocolos DTLS e CoAP. 2018. Trabalho de Conclusão de Curso (Grau de Bacharel em Ciências da Computação) - Universidade Federal de Santa Catarina, [S. l.], 2018. Disponível em: https://repositorio.ufsc.br/bitstream/handle/123456789/192164/Monografia_Johann_Westphall.pdf?sequence=1&isAllowed=y. Acesso em: 14 jun. 2022.

[ID:106] Autor:Rafael Alberganti de Moraes - Criado em: 2022-06-27 16:10:31 - [ Compartilhar ]

Definição

O CoAP, “Constrained Application Protocol”, ou, em uma tradução aproximada, “Protocolo de Aplicação Restrita”, foi desenvolvido pelo grupo de trabalho CoRE (Constrained Restful Environments) do IETF (SILVA; CARVALHO; NAZARIO, 2012).

O CoAP é um protocolo de transferência de informações da camada de aplicação baseado no método request-response, com o mesmo conjunto de operações básicas se comparado ao HTTP (GET, PUT, POST e DELETE), porém consideravelmente mais simples, consome menos memória, processamento e, consequentemente, energia (BORMANN; CASTELLANI; SHELBY, 2012).

O principal responsável pela redução da complexidade é o uso do UDP ao invés do TCP. O CoAP, diferentemente do UDP que não soluciona este problema, trata a perda de pacotes adicionando uma camada à mensagem para detecção e retransmissão dos pacotes. Por esse motivo, um cabeçalho CoAP tem apenas quatro bytes somados a dois bytes para opções e a resposta da requisição ocupa apenas um byte. Assim, uma requisição geralmente usa de 10 a 20 bytes (WESTPHALL, 2018).

A implementação do CoAP não se atém a um protocolo eficiente para a camada de aplicação, mas supera essa ideia viabilizando uma fácil compatibilidade com requisições HTTP através de proxies. Um proxy é um intermediário com um gateway, que com um lado se comunica usando certo protocolo e com outro lado se comunica usando um protocolo diferente, ou seja, é capaz de ligar protocolos diferente e permitir a troca de informações (BORMANN; CASTELLANI; SHELBY, 2012).

Figura 1 - Compatibilidade entre CoAP e HTTP via proxy

Fonte: BORMANN; CASTELLANI; SHELBY, 2012

Aplicação

Ele é bom em ambientes com recursos limitados: dispositivos com energia limitada, enlaces com baixa largura de banda, redes congestionadas ou com perdas. Em redes congestionadas, CoAP/UDP pode funcionar, porém o MQTT/TCP, alternativa ao CoAP, pode não ser nem capaz de administrar um handshake completo. CoAP pode ser usado onde broadcast e multicast são necessários (Comunicação multicast é uma relação de um para vários endpoints. Dispositivos limitados podem ser associados tanto por sua posição ou propósito, e essas relações podem tanto ser pré-configuradas ou configuradas durante as operações. Exemplo: um grupo de interruptores CoAP onde um simples comando de comunicação para o grupo pode acender ou apagar todas as luzes de um andar específico de um prédio). CoAP é adequado na construção de algo no qual um dispositivo é implantado em modo "report only". Uma vez implantado, o dispositivo apenas reporta dados de volta para o servidor. O CoAP é adequado para redes de comunicações domésticas, posto que ferramentas informativas, equipamentos de controle e de comunicação em redes de Casas Inteligentes precisam ser leves e ter baixo custo (SILVA; CARVALHO; NAZARIO, 2012).

Funcionamento

Figura 2 – Camadas abstratas do CoAP

Fonte: SILVA; CARVALHO; NAZARIO, 2012

As aplicações podem fazer requisições ou receber repostas, sendo que estas mensagens são tratadas pelo protocolo de segurança DTLS e enviadas via UDP.

Figura 3 – Cabeçalho CoAP

Fonte: BORMANN, 2014

Segundo Westphall (2018) os componentes do cabeçalho são:

Version: Indica a versão do protocolo usada, para que os dois lados da comunicação saibam qual versão do protocolo seguir. Caso um valor não conhecido esteja nesse campo, a mensagem deve ser ignorada.

Type:

• Confirmable (0): Mensagem enviada deve ser confirmada pelo receptor através de um “Acknowledgement”, para mensagens com confiabilidade. Essa mensagem é retransmitida com intervalos que crescem exponencialmente até o recebimento do “Ack” ou “Reset”.
• Non-Confirmable (1): Mensagem enviada deve não ser confirmada com “Acknowledgement” e rejeitada caso o receptor não seja capaz de entendê-la.
• Acknowledgement (2): Mensagem enviada como primeira resposta de uma mensagem do tipo Confirmable, identificando o ID da mensagem que está sendo confirmada, indicando seu recebimento.
• Reset (3): Indica que uma mensagem (Confirmable ou Non-Confirmable) foi recebida, mas o receptor não pôde processar adequadamente, provavelmente por não conhecer o contexto adequado da mensagem.

Token Lengh: Indica o tamanho do campo Token, na segunda linha do cabeçalho.

Code: Indica o tipo de requisição que está sendo feita, semelhante ao HTTP, o CoAP implementa os métodos básicos GET, POST, PUT e DELETE. Tratando-se de uma resposta, o campo Code indica o código da resposta pertencendo a uma das três classes: sucesso, erro do cliente ou erro do servidor.

Message ID: É um identificador, normalmente sequencial, para cada mensagem enviada por determinado emissor, o qual não deve ser reutilizado até o “Ack” não ser mais esperado pelo emissor da mensagem.

Token: Contendo de 0 a 8 bytes de informação útil, serve para relacionar a requisição à determinada resposta. Idealmente, deve ser implementado de maneira que o token para o par cliente-servidor seja único.

Options: É um campo usado para definir informações como: URI do destinatário da mensagem, porta do destinatário, caminho do recurso, query (em caso de parametrização), formato do payload, formato de conteúdo aceito como resposta, tempo limite para cache, condicionais de formato como resposta e outras.

Payload: O payload de uma mensagem é a representação do recurso requisitado ao servidor, em caso de GET, ou do recurso enviado ao servidor, em caso de POST ou PUT. Exemplificando: se o cliente fizer a requisição na URI "humidade", e o servidor possuir a informação de que a humidade é de 50%, então essa informação será retornada no campo de payload.

Transmissão de Dados Grandes

O UDP ordena os pacotes enviados, ou seja, a ordem é aleatória, então transmissões muito grandes formadas por mais de um pacote seriam desordenadas em situações como, por exemplo, uma atualização de firmware, essa situação não seria aplicada em simples leituras de sensores, mas em casos em que outras funções maiores são requisitadas (WESTPHALL, 2018).

Para resolver esse problema o CoAP possui uma versão com transmissão em blocos. Cada bloco é enviado com um identificador e uma flag informando se ele é o último bloco. Sendo que cada envio é respondido por um ACK, evitando assim as perdas de pacotes (BORMANN, 2016).

Função Observador

Na arquitetura REST, na maioria das vezes que um cliente deseja receber uma informação do servidor essa ação deve ser feita através de um comando GET para cada leitura. Dessa maneira, caso o cliente deseje receber uma informação periodicamente, ele deve enviar um GET nos intervalos de tempo desejado. No entanto, dispositivos com restrições energéticas permanecem hibernando por muito tempo e o momento em que o comando GET é enviado pode coincidir com o momento de hibernação. Além disso, lidar com GETs periodicamente sobrecarrega o dispositivo. Para não haver perdas de requisições, nem sobrecarga de dispositivos, o CoAP tem a Função Observador. Com esta função, o cliente envia um GET, com uma flag indicando o desejo de atualização periódica, ao servidor (sensor, microcontrolador etc.). O sensor, então, dorme sem perder requisições e envia periodicamente o dado especificado no GET (WESTPHALL, 2018).

Segurança

Assim como o HTTP é combinado com o TLS (Transport Layer Security) com objetivo de obter segurança nas trocas de mensagens, o CoAP é combinado com o DTLS (Datagram Transport Layer Security), para obter segurança semelhante à presente na Web. Desse modo em um sistema que utiliza CoAP ela pode estar sem segurança (NoSec), apresentar um par de chaves pré-estabelecido (Pre-shared key (PSKs)), apresentar um par assimétrico de chaves sem certificado (Raw Public Key) ou as chaves assimétricas apresentam um certificado X.509 (SILVA; CARVALHO; NAZARIO, 2012).

Em muitos casos, a maneira mais desejável para garantir segurança entre cliente e servidor seria usando o TLS, todavia o uso do UDP não permite que o TLS seja utilizado, por isso o DTLS (TLS para datagramas) foi projetado para ser o mais similar ao TLS possível, minimizando novas invenções de seguranças e possibilitando aproveitamento de código e estrutura do TLS (RESCORLA, 2012).

Figura 4 – Registro DTLS

Fonte: KOTHMAYR et al., 2013

Segundo Westphall (2018) os componentes do registro são:

Tipo de Conteúdo da Mensagem: Como no TLS, uma mensagem pode representar quatro situações diferentes: estabelecimento do handshake, mudança de protocolos de segurança, alerta de possível comprometimento de segurança ou uma mensagem da aplicação.

Versão do DTLS: Versões diferentes do DTLS possuem diferentes recursos, algoritmos e maneiras de tratar erros. Por isso, no cabeçalho existe o campo para indicar a versão do protocolo entre duas entidades, a fim de haver compatibilidade no uso do DTLS.

Número de sequência: A principal função do número de sequência é a reordenação de mensagens. No DTLS, cada mensagem recebe um número de sequência específico e quando um dispositivo recebe uma mensagem X ele consegue determinar se X é a próxima mensagem esperada. Se for, ela é processada. Se não for, X é direcionada a uma fila para ser processada no momento correto.

Época da mensagem: A época da mensagem é um campo incrementado a cada troca de configurações de segurança (cipher state change) e serve para mensagens serem interpretadas de acordo com as configurações adequadas. Durante a transmissão, os pacotes sofrem alteração de ordem, sendo posteriormente reordenados pelo número de sequência.

Vetor de Inicialização: Cifras de bloco possuem modos de operação como o CBC (Cipher Block Chaining), no qual a saída de um bloco é usado como entrada para cifrar o bloco seguinte. Na cifra do primeiro bloco é usado um vetor de inicialização, geralmente aleatório, necessário para o destinatário decifrar a mensagem.

Payload: O payload é a mensagem em si, que será interpretada pela aplicação após decifração.

MAC: Assim como no TLS, o MAC é calculado para verificação de integridade e autenticidade da mensagem enviada. Todavia, diferentemente do TLS, no DTLS um erro de MAC implica em um alerta e um descarte da mensagem, sem término de conexão. O MAC é calculado com base em uma chave e a concatenação dos campos presentes na Figura 8, considerando o payload em texto claro e excluindo os campos MAC, MAC cont, padding e PL.

CoAP x MQTT

Figura 5 – Comparação CoAP x MQTT

Fonte: ACERVO LIMA, 2021

Referências Bibliográficas

ACERVO LIMA. Diferença entre os protocolos CoAP e MQTT. [S. l.], 2021. Disponível em: https://acervolima.com/diferenca-entre-os-protocolos-coap-e-mqtt/. Acesso em: 14 jun. 2022.

BORMANN, C. The Constrained Application Protocol (CoAP). 2014. Disponível em: https://tools.ietf.org/html/rfc7252. Acesso em: 14 jun. 2022.

BORMANN, C. Block-Wise Transfers in the Constrained Application Protocol (CoAP). 2016. Disponível em: https://tools.ietf.org/html/rfc7959. Acesso em: 14 jun. 2022.

BORMANN, C.; CASTELLANI, A. P.; SHELBY, Z. Coap: An application protocol for billions of tiny internet nodes. IEEE Internet Computing, v. 16, n. 2, p. 62–67, March 2012. ISSN 1089-7801.

KOTHMAYR, T. et al. Dtls based security and two-way authentication for the internet of things. Ad Hoc Networks, v. 11, n. 8, p. 2710 – 2723, 2013. ISSN 1570-8705. Disponível em: http://www.sciencedirect.com/science/article/pii/S1570870513001029. Acesso em: 14 jun. 2022.

RESCORLA, E. Datagram Transport Layer Security Version 1.2. 2012. Disponível em: https://tools.ietf.org/html/rfc6347. Acesso em: 14 jun. 2022.

SILVA, Aryane Barros Maciel; CARVALHO, Felipe Fadul; NAZARIO, Mariana Dabul. Constrained Application Protocol. [S. l.], 2019. Disponível em: https://www.gta.ufrj.br/ensino/eel878/redes1-2019-1/vf/coap/index.html. Acesso em: 14 jun. 2022.

WESTPHALL, Johann. Desenvolvimento de uma Aplicação com dispositivo IoT usando Protocolos DTLS e CoAP. 2018. Trabalho de Conclusão de Curso (Grau de Bacharel em Ciências da Computação) - Universidade Federal de Santa Catarina, [S. l.], 2018. Disponível em: https://repositorio.ufsc.br/bitstream/handle/123456789/192164/Monografia_Johann_Westphall.pdf?sequence=1&isAllowed=y. Acesso em: 14 jun. 2022.

[ID:105] Autor:Breno Veronesi Miatello - Criado em: 2022-06-27 16:10:28 - [ Compartilhar ]

CoAP

Definição

O CoAP, “Constrained Application Protocol”, ou, em uma tradução aproximada, “Protocolo de Aplicação Restrita”, foi desenvolvido pelo grupo de trabalho CoRE (Constrained Restful Environments) do IETF (SILVA; CARVALHO; NAZARIO, 2012).

O CoAP é um protocolo de transferência de informações da camada de aplicação baseado no método request-response, com o mesmo conjunto de operações básicas se comparado ao HTTP (GET, PUT, POST e DELETE), porém consideravelmente mais simples, consome menos memória, processamento e, consequentemente, energia (BORMANN; CASTELLANI; SHELBY, 2012).

O principal responsável pela redução da complexidade é o uso do UDP ao invés do TCP. O CoAP, diferentemente do UDP que não soluciona este problema, trata a perda de pacotes adicionando uma camada à mensagem para detecção e retransmissão dos pacotes. Por esse motivo, um cabeçalho CoAP tem apenas quatro bytes somados a dois bytes para opções e a resposta da requisição ocupa apenas um byte. Assim, uma requisição geralmente usa de 10 a 20 bytes (WESTPHALL, 2018).

A implementação do CoAP não se atém a um protocolo eficiente para a camada de aplicação, mas supera essa ideia viabilizando uma fácil compatibilidade com requisições HTTP através de proxies. Um proxy é um intermediário com um gateway, que com um lado se comunica usando certo protocolo e com outro lado se comunica usando um protocolo diferente, ou seja, é capaz de ligar protocolos diferente e permitir a troca de informações (BORMANN; CASTELLANI; SHELBY, 2012).

Figura 1 - Compatibilidade entre CoAP e HTTP via proxy

Fonte: BORMANN; CASTELLANI; SHELBY, 2012

Aplicação

Ele é bom em ambientes com recursos limitados: dispositivos com energia limitada, enlaces com baixa largura de banda, redes congestionadas ou com perdas. Em redes congestionadas, CoAP/UDP pode funcionar, porém o MQTT/TCP, alternativa ao CoAP, pode não ser nem capaz de administrar um handshake completo. CoAP pode ser usado onde broadcast e multicast são necessários (Comunicação multicast é uma relação de um para vários endpoints. Dispositivos limitados podem ser associados tanto por sua posição ou propósito, e essas relações podem tanto ser pré-configuradas ou configuradas durante as operações. Exemplo: um grupo de interruptores CoAP onde um simples comando de comunicação para o grupo pode acender ou apagar todas as luzes de um andar específico de um prédio). CoAP é adequado na construção de algo no qual um dispositivo é implantado em modo "report only". Uma vez implantado, o dispositivo apenas reporta dados de volta para o servidor. O CoAP é adequado para redes de comunicações domésticas, posto que ferramentas informativas, equipamentos de controle e de comunicação em redes de Casas Inteligentes precisam ser leves e ter baixo custo (SILVA; CARVALHO; NAZARIO, 2012).

Funcionamento

Figura 2 – Camadas abstratas do CoAP

Fonte: SILVA; CARVALHO; NAZARIO, 2012

As aplicações podem fazer requisições ou receber repostas, sendo que estas mensagens são tratadas pelo protocolo de segurança DTLS e enviadas via UDP.

Figura 3 – Cabeçalho CoAP

Fonte: BORMANN, 2014

Segundo Westphall (2018) os componentes do cabeçalho são:

Version: Indica a versão do protocolo usada, para que os dois lados da comunicação saibam qual versão do protocolo seguir. Caso um valor não conhecido esteja nesse campo, a mensagem deve ser ignorada.

Type:

• Confirmable (0): Mensagem enviada deve ser confirmada pelo receptor através de um “Acknowledgement”, para mensagens com confiabilidade. Essa mensagem é retransmitida com intervalos que crescem exponencialmente até o recebimento do “Ack” ou “Reset”.
• Non-Confirmable(1): Mensagem enviada deve não ser confirmada com “Acknowledgement” e rejeitada caso o receptor não seja capaz de entendê-la.
• Acknowledgement (2): Mensagem enviada como primeira resposta de uma mensagem do tipo Confirmable, identificando o ID da mensagem que está sendo confirmada, indicando seu recebimento.
• Reset (3): Indica que uma mensagem (Confirmable ou Non-Confirmable) foi recebida, mas o receptor não pôde processar adequadamente, provavelmente por não conhecer o contexto adequado da mensagem.

Token Lengh: Indica o tamanho do campo Token, na segunda linha do cabeçalho.

Code: Indica o tipo de requisição que está sendo feita, semelhante ao HTTP, o CoAP implementa os métodos básicos GET, POST, PUT e DELETE. Tratando-se de uma resposta, o campo Code indica o código da resposta pertencendo a uma das três classes: sucesso, erro do cliente ou erro do servidor.

Message ID: É um identificador, normalmente sequencial, para cada mensagem enviada por determinado emissor, o qual não deve ser reutilizado até o “Ack” não ser mais esperado pelo emissor da mensagem.

Token: Contendo de 0 a 8 bytes de informação útil, serve para relacionar a requisição à determinada resposta. Idealmente, deve ser implementado de maneira que o token para o par cliente-servidor seja único.

Options: É um campo usado para definir informações como: URI do destinatário da mensagem, porta do destinatário, caminho do recurso, query (em caso de parametrização), formato do payload, formato de conteúdo aceito como resposta, tempo limite para cache, condicionais de formato como resposta e outras.

Payload: O payload de uma mensagem é a representação do recurso requisitado ao servidor, em caso de GET, ou do recurso enviado ao servidor, em caso de POST ou PUT. Exemplificando: se o cliente fizer a requisição na URI "humidade", e o servidor possuir a informação de que a humidade é de 50%, então essa informação será retornada no campo de payload.

Transmissão de Dados Grandes

O UDP ordena os pacotes enviados, ou seja, a ordem é aleatória, então transmissões muito grandes formadas por mais de um pacote seriam desordenadas em situações como, por exemplo, uma atualização de firmware, essa situação não seria aplicada em simples leituras de sensores, mas em casos em que outras funções maiores são requisitadas (WESTPHALL, 2018).

Para resolver esse problema o CoAP possui uma versão com transmissão em blocos. Cada bloco é enviado com um identificador e uma flag informando se ele é o último bloco. Sendo que cada envio é respondido por um ACK, evitando assim as perdas de pacotes (BORMANN, 2016).

Função Observador

Na arquitetura REST, na maioria das vezes que um cliente deseja receber uma informação do servidor essa ação deve ser feita através de um comando GET para cada leitura. Dessa maneira, caso o cliente deseje receber uma informação periodicamente, ele deve enviar um GET nos intervalos de tempo desejado. No entanto, dispositivos com restrições energéticas permanecem hibernando por muito tempo e o momento em que o comando GET é enviado pode coincidir com o momento de hibernação. Além disso, lidar com GETs periodicamente sobrecarrega o dispositivo. Para não haver perdas de requisições, nem sobrecarga de dispositivos, o CoAP tem a Função Observador. Com esta função, o cliente envia um GET, com uma flag indicando o desejo de atualização periódica, ao servidor (sensor, microcontrolador etc.). O sensor, então, dorme sem perder requisições e envia periodicamente o dado especificado no GET (WESTPHALL, 2018).

Segurança

Assim como o HTTP é combinado com o TLS (Transport Layer Security) com objetivo de obter segurança nas trocas de mensagens, o CoAP é combinado com o DTLS (Datagram Transport Layer Security), para obter segurança semelhante à presente na Web. Desse modo em um sistema que utiliza CoAP ela pode estar sem segurança (NoSec), apresentar um par de chaves pré-estabelecido (Pre-shared key (PSKs)), apresentar um par assimétrico de chaves sem certificado (Raw Public Key) ou as chaves assimétricas apresentam um certificado X.509 (SILVA; CARVALHO; NAZARIO, 2012).

Em muitos casos, a maneira mais desejável para garantir segurança entre cliente e servidor seria usando o TLS, todavia o uso do UDP não permite que o TLS seja utilizado, por isso o DTLS (TLS para datagramas) foi projetado para ser o mais similar ao TLS possível, minimizando novas invenções de seguranças e possibilitando aproveitamento de código e estrutura do TLS (RESCORLA, 2012).

Figura 4 – Registro DTLS

Fonte: KOTHMAYR et al., 2013

Segundo Westphall (2018) os componentes do registro são:

Tipo de Conteúdo da Mensagem: Como no TLS, uma mensagem pode representar quatro situações diferentes: estabelecimento do handshake, mudança de protocolos de segurança, alerta de possível comprometimento de segurança ou uma mensagem da aplicação.

Versão do DTLS: Versões diferentes do DTLS possuem diferentes recursos, algoritmos e maneiras de tratar erros. Por isso, no cabeçalho existe o campo para indicar a versão do protocolo entre duas entidades, a fim de haver compatibilidade no uso do DTLS.

Número de sequência: A principal função do número de sequência é a reordenação de mensagens. No DTLS, cada mensagem recebe um número de sequência específico e quando um dispositivo recebe uma mensagem X ele consegue determinar se X é a próxima mensagem esperada. Se for, ela é processada. Se não for, X é direcionada a uma fila para ser processada no momento correto.

Época da mensagem: A época da mensagem é um campo incrementado a cada troca de configurações de segurança (cipher state change) e serve para mensagens serem interpretadas de acordo com as configurações adequadas. Durante a transmissão, os pacotes sofrem alteração de ordem, sendo posteriormente reordenados pelo número de sequência.

Vetor de Inicialização: Cifras de bloco possuem modos de operação como o CBC (Cipher Block Chaining), no qual a saída de um bloco é usado como entrada para cifrar o bloco seguinte. Na cifra do primeiro bloco é usado um vetor de inicialização, geralmente aleatório, necessário para o destinatário decifrar a mensagem.

Payload: O payload é a mensagem em si, que será interpretada pela aplicação após decifração.

MAC: Assim como no TLS, o MAC é calculado para verificação de integridade e autenticidade da mensagem enviada. Todavia, diferentemente do TLS, no DTLS um erro de MAC implica em um alerta e um descarte da mensagem, sem término de conexão. O MAC é calculado com base em uma chave e a concatenação dos campos presentes na Figura 8, considerando o payload em texto claro e excluindo os campos MAC, MAC cont, padding e PL.

CoAP x MQTT

Fonte: ACERVO LIMA, 2021

Referências Bibliográficas

ACERVO LIMA. Diferença entre os protocolos CoAP e MQTT. [S. l.], 2021. Disponível em: https://acervolima.com/diferenca-entre-os-protocolos-coap-e-mqtt/. Acesso em: 14 jun. 2022.

BORMANN, C. The Constrained Application Protocol (CoAP). 2014. Disponível em: https://tools.ietf.org/html/rfc7252. Acesso em: 14 jun. 2022.

BORMANN, C. Block-Wise Transfers in the Constrained Application Protocol (CoAP). 2016. Disponível em: https://tools.ietf.org/html/rfc7959. Acesso em: 14 jun. 2022.

BORMANN, C.; CASTELLANI, A. P.; SHELBY, Z. Coap: An application protocol for billions of tiny internet nodes. IEEE Internet Computing, v. 16, n. 2, p. 62–67, March 2012. ISSN 1089-7801.

KOTHMAYR, T. et al. Dtls based security and two-way authentication for the internet of things. Ad Hoc Networks, v. 11, n. 8, p. 2710 – 2723, 2013. ISSN 1570-8705. Disponível em: http://www.sciencedirect.com/science/article/pii/S1570870513001029. Acesso em: 14 jun. 2022.

RESCORLA, E. Datagram Transport Layer Security Version 1.2. 2012. Disponível em: https://tools.ietf.org/html/rfc6347. Acesso em: 14 jun. 2022.

SILVA, Aryane Barros Maciel; CARVALHO, Felipe Fadul; NAZARIO, Mariana Dabul. Constrained Application Protocol. [S. l.], 2019. Disponível em: https://www.gta.ufrj.br/ensino/eel878/redes1-2019-1/vf/coap/index.html. Acesso em: 14 jun. 2022.

WESTPHALL, Johann. Desenvolvimento de uma Aplicação com dispositivo IoT usando Protocolos DTLS e CoAP. 2018. Trabalho de Conclusão de Curso (Grau de Bacharel em Ciências da Computação) - Universidade Federal de Santa Catarina, [S. l.], 2018. Disponível em: https://repositorio.ufsc.br/bitstream/handle/123456789/192164/Monografia_Johann_Westphall.pdf?sequence=1&isAllowed=y. Acesso em: 14 jun. 2022.

[ID:104] Autor:Leonardo de Oliveira Domingues - Criado em: 2022-06-27 16:10:17 - [ Compartilhar ]

RESUMO

            O consumo médio de climatizadores é extremamente alto, sendo assim, é possível realizar um controle para não afetar a sua performance com o objetivo de reduzir o gasto médio. A ideia é realizar um controle e monitoramento de dados do climatizador e do laboratório de robótica. Para a realização será necessário um microcontrolador esp32, sensores de corrente elétrica ACS712, sensor de temperatura DS18B20, máquina virtual, servidor web e VS Code. Aplicando os sensores amperímetros para medir a corrente elétrica dos climatizadores e o sensor de temperatura para medir em quantos graus está o laboratório e mandando todos esses dados por meio do esp32 para a máquina virtual, que receberá esses dados e por meio do código desenvolvido no VS Code irá controlar o funcionamento do climatizador e realizar os gráficos para ser apresentado no servidor web. Por meio deste projeto pretende-se gerar gráficos apresentando tais dados e controlar o climatizador a fim de reduzir o consumo de energia elétrica do IFSP Campus Catanduva. Com o sucesso do projeto, é possível ser implementado em todas as salas do IFSP, reduzindo o consumo e assim reduzindo os gastos.

FUNDAMENTAÇÃO TEÓRICA

            Com o intuito de reduzir o consumo de energia elétrica na sala de robótica do IFSP campus Catanduva, este projeto será realizado visando aprimorar o funcionamento e prevenir o mau uso dos climatizadores.

       O consumo médio de uma residência fica em torno de 173,7 kWh/mês, isso em toda a região Sudeste, se formos analisar apenas o estado de São Paulo temos um consumo médio de 169,9 kWh/mês, de acordo com o Anuário Estatístico de Energia Elétrica 2021 da EPE (Empresa de Pesquisa Energética, do Governo Federal). Uma residência brasileira no geral, consome em média 165,1 kWh/mês, segundo essa mesma fonte. Levando em conta que o projeto será realizado dentro de uma instituição de ensino, sabemos que o consumo médio pode ser muito mais elevado do que em relação a uma residência, porém para efeito de comparação vamos utilizar uma residência.

      O funcionamento do ar-condicionado é por meio da sucção do ar ambiente, que será conduzido através da serpentina do evaporador, este ar entra em contato com um gás refrigerante que está em estado líquido. Basicamente o ar-condicionado resfria o ar quente presente no ambiente devolvendo-o em uma temperatura baixa, segundo Consul. Um esquema representando o ar condicionado pode ser visto na figura 1.

Figura 1 - 

Fonte: 

       Pegando um ar-condicionado de 18.000 BTUs se observa que o seu consumo médio gira em torno de 32,3 kWh e 34,2 kWh, segundo Yuri Correa, redação do portal WebArCondicionado. Ou seja, apenas um ar-condicionado de 18.000 BTUs ligado apenas 1hr por dia gera um gasto mínimo de 32,3 kWh, se um ar-condicionado desse ligado por 6horas em um dia, já ultrapassaria o consumo médio de uma residência brasileira.

          Pensando sobre isso e tendo em vista que uma instituição de ensino como o Instituto Federal de São Paulo possui diversos ar-condicionado entende-se que o gasto proveniente dos climatizadores possuem um alto impacto nos gastos mensais da instituição. Para reduzir os gastos e pela necessidade de se ter um controle dos climatizadores, para não manter ligado sem necessidade, o projeto foi realizado por meio de um sistema IoT (Internet of Things).

         A internet das coisas promove a interação de diversos aparelhos, sensores, servidores, tanto físicos quanto virtuais, as informações de sensores, instalados em qualquer ambiente por exemplo, precisa ser enviada para servidores na nuvem e com esses dados realizar ações sobre o ambiente, de acordo com Alan Fernandes. Com a crescente difusão do conhecimento sobre IoT muitos sistemas de controle provavelmente serão implementados utilizando tal tecnologia, por não precisar de um servidor local para operar o sistema de controle.

          As instituições de ensino desempenham um papel muito relevante na formação de cidadãos conscientes e responsáveis em relação às questões socioeconômicas e ambientais, segundo Adailton. As instituições precisam ser exemplos para os alunos que ali estão, pois, tendo um melhor controle dos gastos da instituição alguns alunos podem ser influenciados e começar a economizar também.

OBJETIVOS

            OBJETIVO GERAL

• Controlar e monitorar os climatizadores.

OBJETIVOS ESPECÍFICOS

• Monitorar a temperatura de uma sala de aula do IFSP;
• Fazer o controle dos climatizadores para reduzir o consumo de energia elétrica.
• Fazer a aquisição da corrente elétrica dos climatizadores.         

MATERIAIS E MÉTODOS

• ESP 32;
• Sensor de temperatura;
• Sensor de corrente elétrica;
• Máquina virtual nos servidores da Amazon;
• Servidor web;
• Visual Studio Code;
• Fonte de alimentação.

O projeto vai ser implementado no laboratório de robótica no IFSP - Campus Catanduva, onde será realizado testes nos climatizadores e todo o projeto será testado nesta sala, podendo ampliar sua aplicação para o restante do campus dependendo dos seus resultados.

Figura 2 - Laboratório de Robótica.

Fonte: Autoral

Todo o código está sendo desenvolvido e modificado através do Visual Studio Code, plataforma de edição de código fonte e conexão com máquina virtual em geral, neste projeto será utilizado uma máquina virtual localizada nos servidores da AWS (Amazon Web Services). Os sensores de temperatura e corrente elétrica farão a comunicação com a placa ESP32 e todos os dados serão enviados para um servidor na nuvem que armazenará os dados em um banco de dados MySQL.

Figura 3 - VS Code conectado à máquina virtual.

Fonte: Autoral

Figura 4 - Microcontrolador ESP32.

Fonte: Autoral

Figura 5 - Sensor ACS712.

Fonte: Autoral

A figura 4 representa o microcontrolador ESP32 com conexão bluetooth e wifi, que foi utilizado na aquisição de dados dos sensores de corrente elétrica (figura 5), sensor de temperatura (figura 6) e fonte de alimentação (figura 7).

Figura 6 - Sensor DS18B20.

Fonte: Autoral

Figura 7 - Fonte de alimentação.

Fonte: Autoral

A interface web desenvolvida será apresentada no site http://smartcampus.ctd.ifsp.edu.br onde será possível observar um gráfico com os valores da temperatura e da corrente ao longo do tempo. Os dados da corrente do ar condicionado será utilizado para saber se o ar condicionado está ligado ou desligado, gerando uma economia de energia quando não é necessário que ele esteja ligado.

PLANO DE TRABALHO

Tabela 5.1 Metas estabelicidas para a pesquisa.

Os indicadores de cada uma das metas serão:

• Meta 1: A confirmação de que o pré-projeto foi recebido;
• Meta 2: A confirmação de recebimento dos produtos por algum dos membros do projeto;
• Meta 3: Um gráfico apresentando as informações do laboratório em que será realizado o projeto, gráfico temperatura x tempo;
• Meta 4: Um gráfico apresentando as informações dos climatizadores instalados no laboratório em que será realizado o projeto, gráfico corrente elétrica x tempo;
• Meta 5: A confirmação de que o vídeo foi recebido;
• Meta 6: Ver se os dados coletados pelos sensores estão sendo apresentados no site do smart campus.
• Meta 7: Com os dados em mãos poderá ser feita a análise, pra ver se os climatizadores estão desligando quando não há necessidade de estarem ligados;
• Meta 8: A confirmação de que o relatório final foi recebido.

VIABILIDADE DE EXECUÇÃO – ORÇAMENTO

            Para realizar este projeto foi necessário adquirir uma placa de desenvolvimento conhecida por esp32, no valor de aproximadamente R$40,00, dois sensores de corrente elétrica, ACS712 30A, para usar nos climatizadores no valor de, aproximadamente, R$25,00 a unidade e um sensor de temperatura DS18B20 para medir a temperatura da sala no valor de, aproximadamente, R$17,00. Todos os componentes foram adquiridos sem ajuda financeira e sem patrocínios financeiros, mas em relação à estrutura podemos contar com toda a infraestrutura do IFSP Campus Catanduva para realização do projeto.

RESULTADOS ESPERADOS E DISSEMINAÇÃO

          A partir da utilização e implementação dos sensores de corrente elétrica e de temperatura espera-se obter dois gráficos, um de temperatura x tempo e outro de corrente elétrica x tempo, estes gráficos serão apresentados em um site web de acesso livre, sendo esse site o smart campus de Catanduva onde possui diversos outros projetos.

        Este projeto pode ser considerado uma “inovação local” considerando que o IFSP de Catanduva não possui um sistema desse implementado no campus, porém fora do ambiente do campus esse projeto não pode ser considerado uma inovação pois já possuem outros projetos nessa área e com o mesmo objetivo.

          Para realizar a divulgação dos resultados será realizado um artigo para a Mostra PeEx e o todos os resultados do projeto poderão ser acompanhados através do site em que ele ficará disponibilizado, e o circuito de teste realizado na prática pode ser visto pelas figuras 8 e 9.

Figura 8 - Circuito de teste completo - Corrente.

Fonte: Autoral

Figura 9 - Circuito de teste completo - Temperatura.

Fonte: Autoral

REFERÊNCIAS BIBLIOGRÁFICAS

CORREA, Yuri. Qual o consumo de um ar condicionado de 18.000 BTUs. Porto Alegre: Web Ar Condicionado, 2019. Web Site. Disponível em: https://www.webarcondicionado.com.br/qual-o-consumo-de-um-ar-condicionado-de-18-000-btu. Acesso em: 09 mai. 2022.

CONSUL. Saiba tudo sobre Ar-Condicionado. Web Site. Disponível em: https://www.consul.com.br/facilita-consul/bem-pensado-para-voce/tudo-sobre-ar-condicionado. Acesso em: 09 mai. 2022

FERNANDES, Alan (et al). Monitorando Dados e Gerenciando Alertas em um Sistema para Controle de Aparelhos de Ar Condicionado. In: SEMINÁRIO INTEGRADO DE SOFTWARE E HARDWARE (SEMISH), 47., 2020, Cuiabá. Anais [...]. Porto Alegre: Sociedade Brasileira de Computação, 2020. p. 139-150. ISSN 2595-6205. DOI: https://doi.org/10.5753/semish.2020.11324.

GIACOMINI, Gabriela. Vídeo: Como funciona o Ar-Condicionado. Porto Alegre: Web Ar Condicionado, 2019.Web Site. Disponível em: https://www.consul.com.br/facilita-consul/bem-pensado-para-voce/tudo-sobre-ar-condicionado. Acesso em: 09 mai. 2022.

PESQUISA ENERGÉTICA, Empresa de. Anuário Estatístico de Energia Elétrica 2021: ano base 2020. Brasília: Grupojam Mídia Integrada Eireli, 2021.

SILVA, Adailton Moura da (et al). Sistema embarcado para automação de condicionadores de ar visando economia de energia elétrica no IFS. In: Semana nacional de ciência e tecnologia, 2021.

ROBOCORE. Sensor de temperatura DS18B20 - À Prova de Água. São Paulo: RoboCore, 2021. Disponível em: https://www.robocore.net/sensor-ambiente/sensor-de-temperatura-ds18b20-a-prova-de-agua?gclid=EAIaIQobChMIkP-A4K_W9wIVAcKRCh2koALVEAQYASABEgLRyPD_BwE. Acesso em: 10 mai. 2022.

FILIPEFLOP. Sensor de Corrente ACS712 -30A a +30A. Santa Catarina: FilipeFlop, 2021. Disponível em: https://www.filipeflop.com/produto/sensor-de-corrente-acs712-30a-a-30a/. Acesso em: 10 mai. 2022.

[ID:103] Autor:Guilherme Ramos Mendonca - Criado em: 2022-06-23 19:44:55 - [ Compartilhar ]

RESUMO

Para este projeto de integração e facilitação de gerenciamento de horários de alarmes em escolas (ou outra aplicação semelhante como turnos de escritórios e indústrias) foi desenvolvida uma interface onde é possível acionar, remotamente, o atuador que comanda a sirene, ligada à uma placa que condiciona o sinal para o alto-falante piezoelétrico. A conectividade e gerenciamento ficam à cargo de um ESP32, a programação foi realizada em IDE Arduino e NodeRED. O protocolo de comunicação escolhido foi o MQTT, via Wi-Fi disponível no campus e no local de testes/desenvolvimento.

OBJETIVO 

O objetivo é permitir que o disparo da sirene seja automatizado com o preenchimento de um banco de dados com os horários que cada sirene deve ser acionada. Uma vez programado os dias e horários de cada sirene no banco, o disparo ocorrerá sem interferência do usuário, que também pode acionar manualmente fora dos horários programados e alterar o volume.

METODOLOGIA

O sistema, baseado em plataformas open source e open hardware, usa uma sirene piezoelétrica de central de alarme residencial, recuperada de sucata. Um protótipo foi elaborado e montado em placa de matriz de contatos, sendo acionada por módulo de relês comandado pelo ESP32. Recebendo o sinal de disparo ou no horário programado, o relê é acionado e a sirene é ligada por um tempo programado no ESP e desliga após esse tempo. O teste do sistema foi feito tanto pelo botão da interface para acionamento manual quanto usando horários programados. Os horários são baseados no horário GMT que é obtido da rede pelo ESP no momento da conexão.

CONCLUSÃO

O projeto se mostrou não só estável, mas também relativamente simples e barato para implementação e escalabilidade, permitindo que várias unidades operem concomitantemente na mesma rede ou até mesmo em redes diferentes, se houver necessidade, permitindo o uso em plantas industriais diferentes e o controle e programação de horários de turno por um RH central. Também é necessário destacar a agilidade em mudanças de horários que o sistema pode fornecer, diminuindo o custo com pessoal de monitoramento de horário e também para funções de segurança, como toques personalizados paca incêndios, terremotos, evacuações de emergência, perigos químicos, biológicos e outras ameaças, sendo uma ferramenta a favor da segurança e integridade física dos ocupantes dos locais de instalação.

[ID:102] Autor:Gabriel Della Libera Murari - Criado em: 2022-06-22 00:35:59 - [ Compartilhar ]

 O trabalho tem por objetivo desenvolver um módulo supervisório para monitorar as variáveis dentro de um biodigestor, aqui propõe-se monitorar, a princípio, temperatura e umidade, para assim controlá-las em uma faixa de trabalho ideal para assim aumentar a produção do biogás.

 O sensor utilizado foi um DHT22, escolhido por medir ambas variáveis, além de possuir um encapsulamento próprio, que o torna mais resistente as condições e variações dentro do ambiente de monitoramento.

Figura 1: Sensor DHT22.

 Por meio de uma programação desenvolvida no software Arduino IDE os dados obtidos pelo sensor são armazenados no microcontrolador ESP32, esse possui módulos Wifi e Bluetooth de comunicação integrados em seu chip. Através do módulo Wifi o ESP32 irá se comunicar com o protocolo de comunicação MQTT e assim poderá enviar os dados recebidos para a plataforma de desenvolvimento Node-RED, que é uma plataforma de desenvolvimento  baseada em fluxo para programação visual.

 Essa plataforma foi usada para desenvolver uma página web, que poderá ser acessada remotamente de qualquer celular ou computador, nessa página são mostrados os dados dos sensores e esses são arquivados em um banco de dados em nuvem, localizado nos servidores da Amazon Web Services (AWS). 

Figura 2: Montagem do circuito

Figura 3: Representação gráfica dos dados na dashboard

[ID:101] Autor:Gabriela de Lima Kido - Criado em: 2022-06-11 01:50:23 - [ Compartilhar ]

Atualmente, a indústria farmacêutica vem crescendo devido a evolução da tecnologia e a preocupação com a saúde que elevou a expectativa de vida das pessoas, fazendo assim um aumento na produção e no consumo de medicamentos (SOUZA, 2019). Assim, é necessário o desenvolvimento adequado dos produtos em toda sua cadeia, pois ajuda a evitar a contaminação e danos a saude das pessoas. Uma forma de manter a propriedade do produto final deuse o enfoque na implementação de ambientes controlados denominados salas limpas, que se trata de um ambiente fechado com uma unidade de tratamento de ar (UTA) com os respectivos materiais e insumos que fazem parte do serviço e produto da empresa, tendo a sua utilização como forma de garantir um local necessário para os processos de fabricação e a promoção de medidas preventivas (FINEP, [2022]). O projeto visa a criação de um protótipo de uma sala limpa com o monitoramento remoto e a gestão dos principais parâmetros que a envolvem como, a temperatura e a umidade do ar.  

Metodologia 

Para simular o ambiente da sala limpa, será montada um protótipo com uma caixa acrílica, com coolers e uma vela para o controle da temperatura e um umidificador externo para a umidade. Os dados de temperatura e umidade serão obtidos através do sensor DHT11 e transmitidos pela ESP32 que direcionará para um banco de dados alocado em um servidor na nuvem da Amazon Web Service por meio do protocolo MQTT e com Node-Red será realizado a programação em blocos para o tratamento dos dados e a demonstração gráfica em uma página web. Resultados e Discussão

Na Figura 1 é demonstrado a criação do protótipo da sala limpa e pode-se analisar a estrutura onde o projeto foi colocado em prática.

Figura 1 – Protótipo de uma Sala Limpa

                                                                                                                  Fonte: Autoria própria

A programação do Node-Red e a página web com as apresentações gráficas dos dados coletados é demonstrado na figura 2.

Figura 2 – Protótipo de uma Sala Limpa

Conclusões

Conclui-se que o protótipo da sala limpa atingiu os objetivos pré-estabelecidos que era de controlar a temperatura e a umidade, obtendo-se uma resposta gráfica e rápida mediante as mudanças simuladas.

[ID:100] Autor:Leonardo de Oliveira Domingues - Criado em: 2022-06-10 19:11:28 - [ Compartilhar ]

 Palavras Chave: (ambiente, temperatura, umidade)   

Atualmente, a indústria farmacêutica vem crescendo devido a evolução da tecnologia e a preocupação com a saúde que elevou a expectativa de vida das pessoas, fazendo assim um aumento na produção e no consumo de medicamentos (SOUZA, 2019). Assim, é necessário o desenvolvimento adequado dos produtos em toda sua cadeia, pois ajuda a evitar a contaminação e danos a saude das pessoas. Uma forma de manter a propriedade do produto final deu-se o enfoque na implementação de ambientes controlados denominados salas limpas, que se trata de um ambiente fechado com uma unidade de tratamento de ar (UTA) com os respectivos materiais e insumos que fazem parte do serviço e produto da empresa, tendo a sua utilização como forma de garantir um local necessário para os processos de fabricação e a promoção de medidas preventivas (FINEP, [2022]). O projeto visa a criação de um protótipo de uma sala limpa com o monitoramento remoto e a gestão dos principais parâmetros que a envolvem como, a temperatura e a umidade do ar.

Para simular o ambiente da sala limpa, será montada um protótipo com uma caixa acrílica, com coolers e uma vela para o controle da temperatura e um umidificador externo para a umidade. Os dados de temperatura e umidade serão obtidos através do sensor DHT11 e transmitidos pela ESP32 que direcionará para um banco de dados alocado em um servidor na nuvem da Amazon Web Service por meio do protocolo MQTT e com Node-Red será realizado a programação em blocos para o tratamento dos dados e a demonstração gráfica em uma página web.

Na Figura 1 é demonstrado a criação do protótipo da sala limpa e pode-se analisar a estrutura onde o projeto foi colocado em prática.

Figura 1 – Protótipo de uma Sala Limpa

A programação do Node-Red e a página web com as apresentações gráficas dos dados coletados é demonstrado na figura 2.

Figura 2 Node Red e Dashboard

Conclui-se que o protótipo da sala limpa atingiu os objetivos pré-estabelecidos que era de controlar a temperatura e a umidade, obtendo-se uma resposta gráfica e rápida mediante as mudanças simuladas.

[ID:99] Autor:Breno Veronesi Miatello - Criado em: 2022-06-10 19:00:12 - [ Compartilhar ]

Página Mostra PeEx e demais arquivos no github, segue link abaixo:

https://github.com/pietrabs/ProjetoChaves

[ID:98] Autor:Pietra Bessani Soares - Criado em: 2022-06-10 18:38:30 - [ Compartilhar ]

Pagina mostra PeEx e demais arquivos no github, segue link:

https://github.com/LucasHCunha/ProjetoEmbarcados

[ID:97] Autor:Lucas Henrique da Cunha - Criado em: 2022-06-10 18:38:14 - [ Compartilhar ]

Palavras Chave: Poluentes, Ar limpo, Detecção simultânea   

Introdução

O ar limpo é essencial para a saúde das pessoas; nos últimos anos foi possível encontrar grandes evidencias de que a poluição do ar afeta diversos aspectos da saúde em concentrações inferiores às consideradas anteriormente (ORGANIZAÇÃO MUNDIAL DA SAÚDE, 2021).

Segundo dados da OMS (2022) praticamente toda a população mundial (99%) está exposta a um ar fora dos limites de qualidade estabelecidos pela mesma.

Assim, pode-se salientar a relevância do monitoramento da qualidade do ar, pois permite a coleta, a análise dos dados dos poluentes presentes no ar e a tomada das medidas necessárias para garantir uma boa qualidade do ar (VORMITTAG et al., 2021).

O objetivo geral do projeto é desenvolver um sistema de aquisição de dados das concentrações de alguns gases presentes em um ambiente fechado por meio de sensores de baixo custo e um micro controlador (ESP32), fazer a integração desses dados com a nuvem e uma interface gráfica.

Metodologia

Os componentes principais que foram utilizados na prototipagem deste projeto são: ESP32, ADS1115, DHT22, MICS6814, MQ8.

Primeiramente foi necessário a obtenção da equação da curva de resposta dos sensores em relação ao gas desejado (curva fornecida pelo datasheet do fabricante) e realizar a calibração dos sensores por meio de experimentos em ar limpo; Em seguida foi montado o circuito físico utilizando os componentes citados, de modo que os sensores de gás realizavam a comunicação com a ESP32 por meio do ADS1115 para uma melhor resolução analógica e o DHT22 estava conectado a uma entrada digital.

A partir deste circuito a ESP32 transmitia por meio do protocolo MQTT os dados fornecidos para a instancia EC2 localizada nos servidores da Amazon e armazenava em nuvem no banco de dados RDS, também da Amazon. Assim os dados são apresentados em uma interface gráfica utilizando da plataforma Node-RED.  

Resultados e Discussão

O protótipo do circuito montado é apresentado na a seguir.

E a interface gráfica esta apresentada a seguir.

Os resultados obtidos podem ser vistos em gráficos e tabelas, onde acima foi representada apenas uma das três interfaces criadas, pois são semelhantes entre si, alterando apenas o elemento detectado.

Com os resultados obtidos foi possível comparar a concentração dos gases com os padrões estabelecidos pelos órgãos responsáveis.

Conclusões 

Conclui-se que foi possível criar um sistema de detecção com sensores de baixo custo e a ESP32 que tenha capacidade de apresentar estes dados em uma interface gráfica e armazena-los em um banco de dados na nuvem.

Referências Bibliográficas 

OMS. Organização Mundial da Saúde, Bilhões de pessoas ainda respiram ar insalubre: novos dados da OMS, 2022. Disponível em: https://www.who.int/news/item/04-04-2022-billions-of-people-still-breathe-unhealthy-air-new-who-data. Acesso em: 19 abr. 2022.

OMS. Organização Mundial da Saúde, OMS diretrizes de qualidade do ar global, 2021. Disponível em: https://apps.who.int/iris/bitstream/handle/10665/345329/9789240034228-eng.pdf?sequence=1&isAllowed=y. Acesso em: 19 abr. 2022.

VORMITTAG, E. M. P. A. A. et al. Análise do monitoramento da qualidade do ar no Brasil. ESTUDOS AVANÇADOS, São Paulo, v. 35, n. 102, 23 ago. 2021. DOI 10.1590/s0103-4014.2021.35102.002. Disponível em: https://doi.org/10.1590/s0103-4014.2021.35102.002. Acesso em: 8 mai. 2022.

[ID:96] Autor:Leonardo Bonfim Lopes - Criado em: 2022-06-10 18:30:00 - [ Compartilhar ]

Palavras Chave: Poluentes, Ar limpo, Detecção simultânea

Introdução

O ar limpo é essencial para a saúde das pessoas; nos últimos anos foi possível encontrar grandes evidencias de que a poluição do ar afeta diversos aspectos da saúde em concentrações inferiores às consideradas anteriormente (ORGANIZAÇÃO MUNDIAL DA SAÚDE, 2021).

Segundo dados da OMS (2022) praticamente toda a população mundial (99%) está exposta a um ar fora dos limites de qualidade estabelecidos pela mesma.

Assim, pode-se salientar a relevância do monitoramento da qualidade do ar, pois permite a coleta, a análise dos dados dos poluentes presentes no ar e a tomada das medidas necessárias para garantir uma boa qualidade do ar (VORMITTAG et al., 2021).

O objetivo geral do projeto é desenvolver um sistema de aquisição de dados das concentrações de alguns gases presentes em um ambiente fechado por meio de sensores de baixo custo e um micro controlador (ESP32), fazer a integração desses dados com a nuvem e uma interface gráfica.

Metodologia

Os componentes principais que foram utilizados na prototipagem deste projeto são: ESP32, ADS1115, DHT22, MICS6814, MQ8.

Primeiramente foi necessário a obtenção da equação da curva de resposta dos sensores em relação ao gas desejado (curva fornecida pelo datasheet do fabricante) e realizar a calibração dos sensores por meio de experimentos em ar limpo; Em seguida foi montado o circuito físico utilizando os componentes citados, de modo que os sensores de gás realizavam a comunicação com a ESP32 por meio do ADS1115 para uma melhor resolução analógica e o DHT22 estava conectado a uma entrada digital.

A partir deste circuito a ESP32 transmitia por meio do protocolo MQTT os dados fornecidos para a instancia EC2 localizada nos servidores da Amazon e armazenava em nuvem no banco de dados RDS, também da Amazon. Assim os dados são apresentados em uma interface gráfica utilizando da plataforma Node-RED.  

Resultados e Discussão

O protótipo do circuito montado é apresentado na figura a seguir.

E a interface gráfica esta apresentada a seguir.

Os resultados obtidos podem ser vistos em gráficos e tabelas, onde acima foi representada apenas uma das três interfaces criadas, pois são semelhantes entre si, alterando apenas o elemento detectado.

Com os resultados obtidos foi possível comparar a concentração dos gases com os padrões estabelecidos pelos órgãos responsáveis.

Conclusões

Conclui-se que foi possível criar um sistema de detecção com sensores de baixo custo e a ESP32 que tenha capacidade de apresentar estes dados em uma interface gráfica e armazena-los em um banco de dados na nuvem.

Referencias Bibliograficas

OMS. Organização Mundial da Saúde, Bilhões de pessoas ainda respiram ar insalubre: novos dados da OMS, 2022. Disponível em: https://www.who.int/news/item/04-04-2022-billions-of-people-still-breathe-unhealthy-air-new-who-data. Acesso em: 19 abr. 2022.

OMS. Organização Mundial da Saúde, OMS diretrizes de qualidade do ar global, 2021. Disponível em: https://apps.who.int/iris/bitstream/handle/10665/345329/9789240034228-eng.pdf?sequence=1&isAllowed=y. Acesso em: 19 abr. 2022.

VORMITTAG, E. M. P. A. A. et al. Análise do monitoramento da qualidade do ar no Brasil. ESTUDOS AVANÇADOS, São Paulo, v. 35, n. 102, 23 ago. 2021. DOI 10.1590/s0103-4014.2021.35102.002. Disponível em: https://doi.org/10.1590/s0103-4014.2021.35102.002. Acesso em: 8 mai. 2022.

[ID:95] Autor:Rafael Alberganti de Moraes - Criado em: 2022-06-10 18:29:56 - [ Compartilhar ]

Um dos principais acidentes dentro de um laboratório químico é causado por explosão, que gera a liberação de gases. (Unicamp, 2022)

Para que isso não aconteça, o mercado acaba investindo em instrumentos que possam estar medindo essa quantidade de gás existente no ar. O mercado oferece vários aparelhos que são utilizados para medição de gases, porem eles têm alto custo para ser adquiridos, e normalmente são usados nas indústrias. (Stefan, 2020)

A internet das coisas veio aumentar a qualidade da existência de sistemas e serviços de baixo custo, criando oportunidade especificas em várias áreas. (Muenchen, 2018)

O IOT vem se apresentando como uma das principais tecnologias emergentes, gerando novas aplicações das tecnologias de informação, comunicação e sensoriamento. (ZENELLA, 2014)

Assim com esta frequente inovação tecnológica temos como objetivo a construção de sensores de gases e fumaça com menores custos e integrados via Wi-Fi para um constante monitoramento dos dados.

Metodologia 

O método utilizado para o para a obtenção dos dados foi realizada a partir do módulo ESP32 que faz a obtenção e upload dos dados solicitados. Na ESP foi realizada a programação para calcular os valores tensão (V) e corrente (A) obtidos a partir das leituras dos sensores, após essa obtenção os dados serão enviados via Wi-Fi para uma plataforma de análise via NODE-RED, além disso os dados ficam armazenados em um banco de dados e um web-server criado para acesso local ou remoto pela internet. Para que sejam passíveis estes os acessos, temos como base a utilização de máquinas virtuais em softwares da Amazon Web Service (AWS), a partir de uma instância do tipo EC2 (Amazon Elastic Compute Cloud) (AMAZON WEB SERVICE, 2022), com o auxílio do software Visual Studio Code e ferramentas de programação como o Node-RED (MICROSOFT, 2022; OpenJS Foundation, [2022]). 

Após a obtenção e armazenamento dos dados utilizando a curva retirada do manual, junto com a função da mesma, foi possível obter o valor em ppm das concentrações dos gases analisados. 

Resultados e Discussão 

A partir da programação obtivemos um sistema de monitoramento constante da emissão de gases GLP e fumaça, além do controle da umidade presente no ar. Tudo sendo presentados em dashboards online.

Figura 1: Prototipagem

Figura 2: Prototipagem no NodeRed

Figura 3: Dashboard da temperatura e umidade

Figura 4: Dashboard de gás

 Este controle poderá ser utilizado para supervisão da segurança das salas de química, detectando os gases liberados pelos bicos de bunsen destas salas do prédio, assim como para as cozinhas já que o mesmo também detecta o gás liberado pelos bujões.

Conclusões 

Foi possível apontar que os dados obtidos foram um pouco inconclusivos devido ao baixo tempo de execução e ausência de testes em laboratório devido ao COVID nas datas de entrega do projeto. No entanto o funcionamento do circuito ocorreu dentro do planejado e com pequenos ajustes poderá ser implementado em laboratório.

Agradecimentos 

Como agradecimento para a execução deste projeto gostaríamos de mencionar a instituição de ensino IFSP com a colaboração e disponibilidade dos laboratórios para a montagem do projeto, aos professores Fabiano Tadeu Mathias Costa juntamente ao Marcos Aparecido Chaves Ferreira agradecemos pelo excelente trabalho e auxílio na execução do mesmo.   

[ID:94] Autor:Caio Henrique Stefani - Criado em: 2022-06-10 18:10:07 - [ Compartilhar ]

Palavras-Chave: monitoramento, irrigação, ESP32, remoto.   

A utilização das águas na agricultura é importante por servir como fonte de nutrientes para as culturas, sendo que a irrigação é uma técnica necessária para minimizar a degradação do solo.  Embora a irrigação seja um método bastante utilizado pela agricultura na produção de alimentos, porém enfrenta alguns problemas principalmente em grandes áreas de plantio, tal como a falta de tecnologia para detectar falhas nas tubulações e gerenciamento dos recursos. Em vista da necessidade de acompanhar o desenvolvimento das áreas de plantio, propõe-se elaborar um circuito de medição de dados como temperatura ambiente, pressão da água, umidade do solo e do ar.

Os sensores dispostos ao longo da planta construída, coletam os dados referente a pressão da água na tubulação, temperatura do ambiente, umidade do solo e a umidade relativa do ar. Logo os dados coletados são processados pelas unidades NodeMCU localizadas nas extremidades da planta. Após o processamento, os dados são enviados para o servidor Web implementado em uma máquina virtual na plataforma AWS e com o auxílio da ferramenta de programação Node Red foi elaborada uma Dashboard para visualização dos dados e um sistema de alerta/notificações.

Os dados coletados com o monitoramento remoto, estão expressos a seguir.

Figura 1- Dashboard

Fonte: Autoria Própria   

Tabela 1- Análise da pressão

Fonte: Autoria Própria

Com os dados coletados foi possível determinar parâmetros para indicar falhas de funcionamento, enviar alertas e manter os usuários informados por meio do monitoramento remoto. Na figura 1, são exibidos os gráficos obtidos com o sensor de umidade do solo, umidade relativa do ar, diferença de pressão da água, temperatura do ambiente e as mensagens de informação/alerta. A tabela 1 monstra os parâmetros obtidos com a coleta das informações relacionados a pressão da água na tubulação.

O objetivo de construção da planta de irrigação assim como a coleta de dados de forma remota, analisá-los e disponibilizá-los em uma dashboard, foram alcançados. E para projetos futuros podem ser adicionados mais sensores para melhorar a qualidade dos dados.

[ID:93] Autor:Mateus Cordeiro dos Santos - Criado em: 2022-06-10 17:26:45 - [ Compartilhar ]

Palavras-Chave: monitoramento, irrigação, ESP32, remoto.   

A utilização das águas na agricultura é importante por servir como fonte de nutrientes para as culturas, sendo que a irrigação é uma técnica necessária para minimizar a degradação do solo.  Embora a irrigação seja um método bastante utilizado pela agricultura na produção de alimentos, porém enfrenta alguns problemas principalmente em grandes áreas de plantio, tal como a falta de tecnologia para detectar falhas nas tubulações e gerenciamento dos recursos. Em vista da necessidade de acompanhar o desenvolvimento das áreas de plantio, propõe-se elaborar um circuito de medição de dados como temperatura ambiente, pressão da água, umidade do solo e do ar.

Os sensores dispostos ao longo da planta construída, coletam os dados referente a pressão da água na tubulação, temperatura do ambiente, umidade do solo e a umidade relativa do ar. Logo os dados coletados são processados pelas unidades NodeMCU localizadas nas extremidades da planta. Após o processamento, os dados são enviados para o servidor Web implementado em uma máquina virtual na plataforma AWS e com o auxílio da ferramenta de programação Node Red foi elaborada uma Dashboard para visualização dos dados e um sistema de alerta/notificações.

Os dados coletados com o monitoramento remoto, estão expressos a seguir.

Figura 1- Dashboard

Fonte: Autoria Própria   

Tabela 1- Análise da pressão

Fonte: Autoria Própria

Com os dados coletados foi possível determinar parâmetros para indicar falhas de funcionamento, enviar alertas e manter os usuários informados por meio do monitoramento remoto. Na figura 1, são exibidos os gráficos obtidos com o sensor de umidade do solo, umidade relativa do ar, diferença de pressão da água, temperatura do ambiente e as mensagens de informação/alerta. A tabela 1 monstra os parâmetros obtidos com a coleta das informações relacionados a pressão da água na tubulação.

O objetivo de construção da planta de irrigação assim como a coleta de dados de forma remota, analisá-los e disponibilizá-los em uma dashboard, foram alcançados. E para projetos futuros podem ser adicionados mais sensores para melhorar a qualidade dos dados.

[ID:92] Autor:Lorena Maria Costa do Nascimento - Criado em: 2022-06-10 17:17:02 - [ Compartilhar ]

O presente projeto tem como objetivo desenvolver um sistema eletrônico que possa detectar alterações de ruídos sonoros pré-determinados em ambientes industriais e escolares, com o intuito de obter um lugar mais seguro, agradável e produtivo.

O sensor utilizado é um Microfone Omnidirecional INMP441 (Figura 1), capaz de captar som em todas as direções, além disso já conta com um conversor analógico para digital e um filtro antialiasing, o qual permite a passagem de todas as frequências corretas, cortando as indesejáveis.

Figura 1 - Sensor Microfone Omnidirecional INMP441

Por meio de uma programação, os dados obtidos são tratados e armazenados no microcontrolador ESP32 (Figura 2), que possui um módulo WIFI e um módulo Bluetooth de comunicação integrados ao seu chip. A comunicação com o protocolo MQTT é feita usando a comunicação WIFI da ESP32.

Figura 2 - Microcontrolador ESP32

Para sinalizar visualmente quando o limite de ruído em decibéis é ultrapassado utiliza-se um Led vermelho. Logo, o circuito para obtenção de dados usado no projeto pode ser visto na Figura 3 e a montagem final do projeto na Figura 4.

Figura 3 - Circuito para obtenção de dados

Figura 4 - Montagem final projeto

Para a comunicação com o MQTT foi necessário alugar um servidor no AWS para fazer o armazenamento das informações no banco de dados, que são enviados para o MQTT pela ESP32. O banco de dados utilizado nesse servidor da AWS foi o Mysql, que tem a função de salvar os dados enviados para o MQTT na nuvem. Esses dados são exibidos na web, por meio de um IP público gerado pela instância AWS.

Por meio do Node-RED, uma ferramenta de desenvolvimento baseada em fluxos para programação visual em nós, ou em blocos, foi desenvolvida uma programação (Figura 5) que faz uma demonstração gráfica dos dados obtidos e as apresenta numa página da web (Figura 6).

Figura 5 - Programação Node-RED

Figura 6 - Representação gráfica dos dados coletados

Nas Figuras 4 e 6 é possível ver o Led acesso, já que o limite de ruído estipulado em 70dB foi ultrapassado, emitindo assim o alerta visual.

[ID:90] Autor:Beatriz Miano Paulino - Criado em: 2022-06-09 22:15:05 - [ Compartilhar ]

RESUMO

            O consumo médio de climatizadores é extremamente alto, sendo assim, é possível realizar um controle para não afetar a sua performance com o objetivo de reduzir o gasto médio. A ideia é realizar um controle e monitoramento de dados do climatizador e do laboratório de robótica. Para a realização será necessário um microcontrolador esp32, sensores de corrente elétrica ACS712, sensor de temperatura DS18B20, máquina virtual, servidor web e VS Code. Aplicando os sensores amperímetros para medir a corrente elétrica dos climatizadores e o sensor de temperatura para medir em quantos graus está o laboratório e mandando todos esses dados por meio do esp32 para a máquina virtual, que receberá esses dados e por meio do código desenvolvido no VS Code irá controlar o funcionamento do climatizador e realizar os gráficos para ser apresentado no servidor web. Por meio deste projeto pretende-se gerar gráficos apresentando tais dados e controlar o climatizador a fim de reduzir o consumo de energia elétrica do IFSP Campus Catanduva. Com o sucesso do projeto, é possível ser implementado em todas as salas do IFSP, reduzindo o consumo e assim reduzindo os gastos.

FUNDAMENTAÇÃO TEÓRICA

            Com o intuito de reduzir o consumo de energia elétrica na sala de robótica do IFSP campus Catanduva, este projeto será realizado visando aprimorar o funcionamento e prevenir o mau uso dos climatizadores.

O consumo médio de uma residência fica em torno de 173,7 kWh/mês, isso em toda a região Sudeste, se formos analisar apenas o estado de São Paulo temos um consumo médio de 169,9 kWh/mês, de acordo com o Anuário Estatístico de Energia Elétrica 2021 da EPE (Empresa de Pesquisa Energética, do Governo Federal). Uma residência brasileira no geral, consome em média 165,1 kWh/mês, segundo essa mesma fonte. Levando em conta que o projeto será realizado dentro de uma instituição de ensino, sabemos que o consumo médio pode ser muito mais elevado do que em relação a uma residência, porém para efeito de comparação vamos utilizar uma residência.

O funcionamento do ar-condicionado é por meio da sucção do ar ambiente, que será conduzido através da serpentina do evaporador, este ar entra em contato com um gás refrigerante que está em estado líquido. Basicamente o ar-condicionado resfria o ar quente presente no ambiente devolvendo-o em uma temperatura baixa, segundo Consul. Um esquema representando o ar condicionado pode ser visto na figura 1.

Figura 1 – Esquema climatizador.

Fonte: WebArCondicionado.

Pegando um ar-condicionado de 18.000 BTUs se observa que o seu consumo médio gira em torno de 32,3 kWh e 34,2 kWh, segundo Yuri Correa, redação do portal WebArCondicionado. Ou seja, apenas um ar-condicionado de 18.000 BTUs ligado apenas 1hr por dia gera um gasto mínimo de 32,3 kWh, se um ar-condicionado desse ligado por 6horas em um dia, já ultrapassaria o consumo médio de uma residência brasileira.

Pensando sobre isso e tendo em vista que uma instituição de ensino como o Instituto Federal de São Paulo possui diversos ar-condicionado entende-se que o gasto proveniente dos climatizadores possuem um alto impacto nos gastos mensais da instituição. Para reduzir os gastos e pela necessidade de se ter um controle dos climatizadores, para não manter ligado sem necessidade, o projeto foi realizado por meio de um sistema IoT (Internet of Things).

A internet das coisas promove a interação de diversos aparelhos, sensores, servidores, tanto físicos quanto virtuais, as informações de sensores, instalados em qualquer ambiente por exemplo, precisa ser enviada para servidores na nuvem e com esses dados realizar ações sobre o ambiente, de acordo com Alan Fernandes. Com a crescente difusão do conhecimento sobre IoT muitos sistemas de controle provavelmente serão implementados utilizando tal tecnologia, por não precisar de um servidor local para operar o sistema de controle.

  As instituições de ensino desempenham um papel muito relevante na formação de cidadãos conscientes e responsáveis em relação às questões socioeconômicas e ambientais, segundo Adailton. As instituições precisam ser exemplos para os alunos que ali estão, pois, tendo um melhor controle dos gastos da instituição alguns alunos podem ser influenciados e começar a economizar também.

OBJETIVOS

            OBJETIVO GERAL

• Controlar e monitorar os climatizadores.

OBJETIVOS ESPECÍFICOS

• Monitorar a temperatura de uma sala de aula do IFSP;
• Fazer o controle dos climatizadores para reduzir o consumo de energia elétrica.
• Fazer a aquisição da corrente elétrica dos climatizadores.

VIABILIDADE DE EXECUÇÃO – ORÇAMENTO

            Para realizar este projeto foi necessário adquirir uma placa de desenvolvimento conhecida por esp32, no valor de aproximadamente R$40,00, dois sensores de corrente elétrica, ACS712 30A, para usar nos climatizadores no valor de, aproximadamente, R$25,00 a unidade e um sensor de temperatura DS18B20 para medir a temperatura da sala no valor de, aproximadamente, R$17,00. Todos os componentes foram adquiridos sem ajuda financeira e sem patrocínios financeiros, mas em relação à estrutura podemos contar com toda a infraestrutura do IFSP Campus Catanduva para realização do projeto.

RESULTADOS ESPERADOS E DISSEMINAÇÃO

            A partir da utilização e implementação dos sensores de corrente elétrica e de temperatura espera-se obter dois gráficos, um de temperatura x tempo e outro de corrente elétrica x tempo, estes gráficos serão apresentados em um site web de acesso livre, sendo esse site o smart campus de Catanduva onde possui diversos outros projetos.

            Este projeto pode ser considerado uma “inovação local” considerando que o IFSP de Catanduva não possui um sistema desse implementado no campus, porém fora do ambiente do campus esse projeto não pode ser considerado uma inovação pois já possuem outros projetos nessa área e com o mesmo objetivo.

            Para realizar a divulgação dos resultados será realizado um artigo para a Mostra PeEx e o todos os resultados do projeto poderão ser acompanhados através do site em que ele ficará disponibilizado.

[ID:89] Autor:Arthur Braga Zerondi - Criado em: 2022-06-09 10:47:54 - [ Compartilhar ]

Orçamento 

A previsão dos custo é de gasto de R$400,00 reais, esta dentro de orçamento a compra dos sensores, controlador e atuadores.

Dimensão do projeto

O prototipo sistema será feito dentro de um cubo e lá será colocado tipos de gases que possam ser utilizados no laboratório de química do IFSP.

Agenda

As reuniões serão presencias nas terças-ferias com pelo menos 02:00 horas e nos outros dias da semana serão por meio remoto com no máximo de 02:00h por dia.

Indicadores

O principal indicador é a apresentação do dashboard que estará no site do NodeRed.

Figura 1: Exemplo de detector de gases

[ID:87] Autor:Caio Henrique Stefani - Criado em: 2022-05-12 19:36:50 - [ Compartilhar ]

Motivação do projeto 

A utilização de placas solares vem aumentado por conta do preço da energia, junto a isso vem a necessidade de equipamentos para auxiliar as medições tanto de produção quanto de consumo. Com essa necessidade tem os produtos vendidos no mercado que tem uma grande variedade de preços, porém é restrito a uma faixa de produção baixa em produtos mais baratos, e em produtos mais caros geralmente não consegue suprir a necessidade de algumas pessoas. Assim se deu a ideia de utilizar um projeto já desenvolvido para aumentar essa faixa de produção.

Objetivos do Projeto

O objetivo é desenvolver um MPPT com supervisão via aplicativo, onde nele será indicado a energia produzida e armazenada nas baterias e com seus horários de pico. A primeira parte é dada pelo desenvolvimento do PCI utilizando o software Proteus 8.1, indicando as ligações e componentes utilizados. A segunda par é a PCI física. A terceira parte é fazer a soldagem dos componentes nas PCI. A quarta parte é fazer a implementação do programa e fazer os testes necessários. A quinta e ultima parte é fazer o desenvolvimento do aplicativo e fazer sua implementação.

Referências 

https://www.instructables.com/DIY-1kW-MPPT-Solar-Charge-Controller/

[ID:86] Autor:Afonso Cesar Denadai - Criado em: 2022-05-11 18:21:17 - [ Compartilhar ]

Diante as situações climáticas atuais do Brasil, relacionadas ao alto índice de desmatamento e poluição, a baixa umidade do ar é um problema que afeta a população em tempos de seca ou de temperatura elevada, comprometendo seriamente sua saúde, como os problemas respiratórios. Com isso, o presente projeto propõe a construção de um sistema de monitoramento da temperatura e da umidade relativa do ar em ambientes internos.

[ID:84] Autor:Lucas Henrique da Cunha - Criado em: 2022-05-02 13:59:16 - [ Compartilhar ]

     Diante as situações climáticas atuais do Brasil, relacionadas ao alto índice de desmatamento e poluição, a baixa umidade do ar é um problema que afeta a população em tempos de seca ou de temperatura elevada, comprometendo seriamente sua saúde, como os problemas respiratórios. Com isso, o presente projeto propõe a construção de um sistema de monitoramento da temperatura e da umidade relativa do ar em ambientes internos.

[ID:83] Autor:Pietra Bessani Soares - Criado em: 2022-05-02 13:58:02 - [ Compartilhar ]

Contextualizando

  O descarte inapropriado de matéria orgânica gera gases poluentes que contaminam o ar e o solo. Uma das alternativas a esta contaminação do solo são os biodigestores: sendo recipientes onde podemos armazenar restos orgânicos para produzir biogás através de biodigestão anaeróbica (RIBEIRO, 2020). O biogás tem se apresentado como uma alternativa barata e eficaz ao gás de cozinha derivado de petróleo (GLP — Gás Liquefeito de Petróleo), principalmente em comunidades rurais.  Segundo Barreira (2011), a matéria-prima para produção do biogás (também conhecida como biomassa) é uma das mais abundantes e baratas do mundo, podendo ser obtida de inúmeras formas.  

   Segundo os dados divulgados pela EMPRESA de PESQUISA ENERGÉTICA — EPE (2015), as maiores fontes de geração do biogás por biodigestor no Brasil são: os aterros sanitários (51%), a indústria de alimentos e bebidas (25%), a suíno cultura (14%) e o lodo de esgoto (6%).

   Atualmente existem diversos modelos de biodigestores disponíveis no mercado brasileiro, projetados conforme a categoria de dejetos que serão decompostos por eles. Entretanto, a ampla maioria destes modelos carece de um sistema de controle associado a sua produção do biogás, dificultando a obtenção dados como: a quantidade do gás produzido, a qualidade do gás e o seu tempo de produção.

Objetivo

   O objetivo do presente trabalho é possibilitar a análise remota de dados sobre a produção de biogás em biodigestores de uso específico. Com base nesta análise, poderemos obter dados sobre quais restos de alimentos deverão ser separados e armazenados no biodigestor, a quantidade em volume de gás que estes alimentos podem produzir, o tempo gasto no processo de digestão destes e a qualidade do gás produzido no biodigestor.

  Para tanto, serão monitoradas condições físicas de ambiente consideradas fundamentais (KUNZ, STEINMETZ E AMARAL, 2019) durante o processo de biodigestão anaeróbica:

• Temperatura: A temperatura considerada ideal para manter vivos os microorganismos responsáveis pela digestão da matéria orgânica no biodigestor é de 30 á 40 graus Celsius;
•  Percentual de Hidrogênio (p.H): Para se preservar a existência dos microorganismos decompositores o p.H. deve se manter próximo á neutralidade 6 á 7 por cento;
• Pressão: A pressão no sistema biodigestor não poderá exceder o seu limite na estrutura, tendo em vista que a área do biodigestor não será alterada com o aumento de volume do gás;
• Volume: O volume de gás (em litros) será a forma de quantificar o tanto de gás produzido pelo sistema;
• Percentual de Metano: O percentual de metano será a forma de quantificar (em porcentagem) a qualidade do gás produzido pelo biodigestor, que segundo especialistas são de 50 á 70%  do gás.

Métodos e Desenvolvimento

  A escolha dos sensores que serão utilizados por este Módulo deverá basear-se no resultado de ensaios feitos em biodigestores Dry Digestion de batelada (KUNZ, STEINMETZ E AMARAL, 2019), seguindo as recomendações das normas alemã DIN (38.414, 2008) e européia VDI (4630, 2006), onde poderemos determinar com precisão quais eventos físicos poderão intervir na aquisição de dados pelos sensores. De modo geral, os componentes escolhidos para o nosso projeto são:

• Módulo ESP 32 Dev Kit V1;
• Sensor LM35;
• Módulo sensor ultrassônico;
• Módulo sensor de p.H;
• Módulo sensor de metano MQ-5;
• Regulador 7805;
• Capacitores: 1000µf e 10µf;
• Resistores: 10kΩ, 1kΩ, 680Ωe 100Ω;
• Protoboard;
• Leds: vermelho e verde.

[ID:82] Autor:Vinicius Alves - Criado em: 2022-05-01 22:59:47 - [ Compartilhar ]

O descarte inapropriado de matéria orgânica, como restos de alimentos descartados por restaurantes e cozinhas, geram gases poluentes que contaminam o ar e o solo, visando reduzir esse poluentes decidimos elaborar um sistema supervisório que poderá ser utilizado em biodigestores ou sistemas semelhantes. Esses fazem o aproveitamento dos gases gerados pelos restos de alimentos durante o processo de biodigestão anaeróbica. O sistema poderá ser replicado em restaurantes, instituições de ensino e indústrias que tenham interesse em desenvolver sistemas que reaproveitem a matéria orgânica para produção de biogás.

SMART 1 – Definir os sensores que serão utilizados;

SMART 2 – Desenvolver um sistema de aquisição de dados;

SMART 3 – Controlar temperatura e liberação de substâncias no sistema;

SMART 4 – Construir um protótipo do reservatório de gás.

[ID:81] Autor:Gabriela de Lima Kido - Criado em: 2022-05-01 21:25:30 - [ Compartilhar ]

Com o intuito de reduzir os gastos vindo dos climatizadores do instituto federal de Catanduva e controlar a temperatura de todas as salas do campus surgiu a ideia de criar um sistema que controle e mantenha a temperatura em determinado setpoint, diminuindo assim o tempo que o ar fica ligado gastando energia.

Objetivos do Projeto

O projeto será bem sucedido se cumprir os seguintes objetivos:

• SMART 1 – monitorar a temperatura de uma sala do IFSP;

• SMART 2 – fazer o controle do climatizador para reduzir o consumo de energia elétrica;

Resultados esperados e seus requisitos

Esperamos conseguir com êxito controlar e manter a temperatura de pelo menos uma sala do instituto, para depois poder ampliar para todo o campus.

• SMART 1 – através de um sensor de temperatura adquirir e apresentar os dados dos climatizadores da sala.

• SMART 2 – analisar pós projeto o consumo de energia antes e depois do sistema de controle.

[ID:80] Autor:Guilherme Ramos Mendonca - Criado em: 2022-05-01 19:13:15 - [ Compartilhar ]

Introdução

O monitoramento da qualidade de líquidos é um procedimento de extrema importância em indústrias, ou até mesmo em nossas casas. O projeto em questão visa realizar o monitoramento remoto de um recipiente controlado, medindo os valores de PPM(partículas por milhão) presentes e o nível de líquido utilizando sensores apropriados.

   Para realizar as medições foi utilizado um sensor de nível de água analógico para o monitoramento no nível da água e um sensor TDS para as medições de condutividade da água.

  O Sensor Módulo Medidor de Qualidade da Água TDS, tem a função de realizar as medições das impurezas encontradas na água. Segundo Ramalho (2009) a condutividade é definida como a capacidade de um material em conduzir corrente elétrica, sendo assim a capacidade de condução depende da presença de íons. 

 Este projeto tem em vista a montagem de um sistema de observação da qualidade da água armazenada em um reservatório, disponibilizando os dados na internet de forma acessível.

Metodologia

O protótipo finalizado contará com o tanque para armazenagem da água, o recipiente terá duas válvulas, com intuito de abastecimento e drenagem.

Para a montagem do site foi utilizado do servidor AWS da amazon para a criação do servidor e o banco de dados para o armazenamento de dados.

O controle do sistema será realizado por uma malha fechada, que de acordo com Maya e Leonardi (2014) é caracterizado por um sistema de controle que impõe as condições das saídas de acordo com as variáveis de entrada. As variáveis de entrada do sistema são dadas pelo medidor de condutividade da água (TDS) e pelo sensor de nível da água.

Figura 1 – Sensor TDS

Figura 2 – Sensor de Nível

Os dados obtidos serão processados através de um microcontrolador modelo ESP 32. O componente será programado para manter a água em um nível de turbidez aceitável, iniciando um processo de drenagem, até o esvaziamento completo do recipiente.

Figura 3 – ESP 32

Resultados e Discussões

Tendo uma bancada de teste pronta juntamente a programação e o banco de dados, foram analisadas as amostras de água dentro de um reservatório com duas válvulas, entrada e saída, junto a um sensor de condutividade TDS. 

Figura 4 - Bancada de testes.

Seus dados foram enviados para um banco de dados de um website web utilizando Node-RED e MQTT, mostrando os valores em um layout criado.

Figura 5 – Layout do Site

Conclusão

Tendo os conhecimentos da importância do uso cotidiano da água. Obteve-se um projeto que alcança as demandas de analisar a condutividade da água armazenada, assim comparando o nível de TDS para relatar se ela é própria de acordo com esse processo, de forma remota com o banco de dados online.

[ID:78] Autor:Leonardo Bozza - Criado em: 2022-04-30 18:49:40 - [ Compartilhar ]

No IFSP campus Catanduva não possui nenhum sistema de monitoramento da qualidade do ar, ou seja, para detectar os principais poluentes do ar. Logo é interessante haver um sistema com essa característica, pois alguns gases são prejudiciais à saúde, e em grandes concentrações pode provocar a morte.

OBJETIVOS

O objetivo é desenvolver um sistema de aquisição de dados das concentrações de alguns gases presente em um ambiente fechado por meio de sensores e um microcontrolador (ESP32), fazer a integração desses com a nuvem e uma interface gráfica.

Além disso, informar o comparativo com os valores definidos por uma norma para possibilitar a análise da condição do ar.

O projeto será bem-sucedido se cumprir os seguintes objetivos:

• SMART 1 - desenvolver um sistema de aquisição de dados;
• SMART 2 - construir um protótipo do sistema de detecção.
• SMART 3 - construir a interface gráfica online com o auxílio do Node-Red.
• SMART 4 – realizar a conexão do protótipo com a interface.
• SMART 5 – escrever o memorial do projeto.

O sistema de detecção de poluentes no ar descrito neste projeto será aplicado em ambientes fechados e com foco em alguns gases poluentes específicos como CO, H₂, NH₃, NO₂, CO₂ e alguns gases inflamáveis, portanto, os demais não serão averiguados e o projeto não poderá ser aplicado para ambientes abertos. 

[ID:76] Autor:Rafael Alberganti de Moraes - Criado em: 2022-04-29 20:55:51 - [ Compartilhar ]

[ID:75] Autor:Higor da Silva Soares - Criado em: 2022-04-29 17:54:05 - [ Compartilhar ]

Quando há uma queimada existe a liberação de gás carbônico (CO2), metano (CH4), monóxido de carbono (CO) e nitroso de oxigênio (N2O). (Fearnside, 2002)

Segunda a resolução nº 491/2018 da CONAMA, para não ser prejudicial, o CO pode apresentar uma concentração de 9ppm, já o CO2 ele pode apresentar concentração 1000ppm. (BRASIL, 2018)

Um dos principais acidentes dentro de um laboratório químico é causado por explosão, que gera a liberação de gases. Dentro de um laboratório um liquido que possui um ponto de fulgor abaixo da temperatura ambiente naquele momento, em uma condição especifica,  pode liberar uma quantidade de vapor que ao se misturar com o ar pode gerar uma mistura inflamável, se essa mistura for se acumulando e se tiver algum meio de ignição, pode acontecer uma explosão.(Unicamp, 2022)

Para que isso não aconteça, o mercado acaba investindo em instrumentos que possam estar medindo essa quantidade de gás existente no ar.

 O mercado oferece vários aparelhos que são utilizados para medição de gases, porem eles tem alto custo para ser adquiridos, e normalmente são usados nas industrias. (Stefan, 2020)

Os seres humanos com o passar dos anos foram evoluindo, e cada vez mais se conectando por meio de novas tecnologias. A internet das coisas veio aumentar a qualidade da existência de sistemas e serviços de baixo custo, criando oportunidade especificas em varias áreas. (Muenchen, 2018)

O IOT vem se apresentando como uma das principais tecnologias emergentes, gerando novas aplicações das tecnologias de informação, comunicação e sensoriamento. (ZENELLA, 2014)

Para sistemas microcontrolados, que é o principal hardware utilizado em IOT, há a existência de sensores que possam estar medindo a quantidade de concentração de gás no ar. Esses sensores que vão ser utilizados são do tipo eletrolíticos. Comparados aos instrumentos industriais, esses são de baixo custo e estão associados a módulos que permitem a conexão com um microcontrolador. O seu funcionamento acontece por meio de uma variação de tensão existente em uma resistência interna que se altera conforme o sensor detecta algum gás, isso torna possível perceber a variação de tensão, que é transmitida na entrada do microcontrolador, que por pode ser analógico ou digital. (HANWEI ELETRONICS, 201-a)

Os sensores da família MQ enviam um sinal analógico para o microprocessador, entretanto o valor analógico emitido pelo sensor tem que ser trabalhado para poder saber o seu real resultado, pois o mesmo não manda um sinal direto. Para que a concentração seja determinada, tem-se que utilizar o manual do sensor para pegar as curvas de atuação do mesmo. No manual há a existência de um gráfico, mostrada na figura 1, que apresenta os valores que corresponde à razão pela concentração do gás em partes por milhão. (Stefan, 2020)

Figura 1: Curva retirada do manual como exemplo

Por meio da analise de vários artigos chegou-se a conclusão que a função que mais se aproxima das curvas apresentadas nos gráficos acima é da forma mostrada na equação (1).

OBJETIVOS

Objetivo geral

Construir um sistema para a detecção e monitoramento de gases para os laboratórios de química do campus por meio de sensores via microcontrolador ESP32.

Objetivos específicos

• Desenvolver um sistema para aquisição de dados.
• Construir Protótipo.
• Implementar os dados adquiridos a uma máquina virtual por meio do AWS.
• Acionar atuadores a partir dos dados enviados para a máquina virtual.
• Realizar memorial do projeto.

MATERIAIS E MÉTODOS

Os materiais que terão maior prioridade para a construção do projeto serão:

• Módulo ESP32 NodeMCU;
• Sensor de humidade e temperatura DHT11
• Sensor de gás inflamável e fumaça MQ-2
• Sensor para gás GLP MQ-135

A partir dos componentes acima o circuito poderá ser montado com estrutura simulada em software onde foi simulado com um Arduino por falta do ESP, porém o mesmo será montado com o ESP no mesmo esquema exemplificado na figura 2.

Figura 2 - Circuito do Projeto

Fonte: própria autoria.

A função do módulo ESP32 será fazer a obtenção e upload dos dados solicitados. Na ESP será realizada a programação para calcular os valores tensão (V) e corrente (A) obtidos a partir das leituras dos sensores, após essa obtenção os dados serão enviados via Wi-Fi para uma plataforma de análise via NODE-RED, além disso os dados ficaram armazenados em um banco de dados e um web-server será criado para acesso local ou remoto pela internet. Para que sejam passíveis estes os acessos, teremos com base a utilização de máquinas virtuais do em softwares da Amazon Web Service (AWS), a partir de uma instância do tipo EC2 (Amazon Elastic Compute Cloud) (AMAZON WEB SERVICE, 2022), com o auxílio do software Visual Studio Code e ferramentas de programação como o Node-RED (MICROSOFT, 2022; OpenJS Foundation, [2022]).

Utilizando a curva retirada do manual, junto com a função da mesma, é possível obter o valor em ppm das concentrações de gases.

RESULTADOS 

Para o desenvolvimento deste projeto obtivemos um sistema de monitoramento constante, da emissão de gases GLP e fumaça, além do controle da umidade presente no ar. Onde os dados monitorados podem ser analisados local ou remotamente por meio de um servidor e um site, criados de modo online para a exibição desse monitoramento.

Para a obtenção dos dados a cima foi necessário o seguinte programa no Node-Red:

Este controle poderá ser utilizado para supervisão da segurança das salas de química, detectando os gases liberados pelos bicos de bunsen destas salas do prédio, assim como para as cozinhas já que o mesmo também detecta o gás liberado pelos bujões.

Além disso, o projeto pode funcionar como um segundo meio de detecção de fumaça destes locais, tendo em vista que um dos sensores utilizados também os capta caso haja algum problema com os detectores de incendo, proporcionando ainda mais segurança nestes casos.

Apesar do alto nível de segurança para incêndios teoricamente já existentes nestes locais, um controle para evitar o início destes incêndios, somente pelos gases liberados ainda é inexistente. Dessa forma, temos um potencial para inovação do projeto no aperfeiçoamento das características de um produto já obrigatoriamente implementado.

A obtenção dos resultados destas supervisões poderá ser utilizada para futuros trabalhos sendo possível assim a divulgação em revistas de artigos científicos ou eventos.

Link para Video do prjeto:  https://youtu.be/eAhjwZ6Lf0U

PROTOCOLO UDP

O que é UDP?

Como todos os protocolos de rede, o UDP é um método padronizado para transferir dados entre dois computadores em uma rede. Comparado a outros protocolos, o UDP realiza este processo de forma simples: envia pacotes (unidades de transmissão de dados) diretamente para um computador de destino sem estabelecer primeiro uma conexão, indicando a ordem dos referidos pacotes ou verificando se eles chegaram como pretendido — Os pacotes UDP são chamados de ‘datagramas’.

Para que o UDP é usado?

O UDP é comumente usado em comunicações sensíveis ao tempo, em que, ocasionalmente, descartar pacotes é melhor do que esperar. O tráfego de voz e vídeo é enviado usando este protocolo porque ambos são sensíveis ao tempo e projetados para lidar com algum nível de perda. Por exemplo, VOIP (voz sobre IP), que é usado por muitos serviços telefônicos baseados na Internet, opera sobre UDP. Isso ocorre porque uma conversa telefônica estática é preferível a uma que seja nítida, mas muito atrasada.

Entenda a estrutura de cabeçalho UDP!

UDP envolve datagramas com um cabeçalho UDP, que contém quatro campos totalizando oito bytes.

Os campos em um cabeçalho UDP são:

• Porta de origem  – a porta do dispositivo que envia os dados. Este campo pode ser definido como zero se o computador de destino não precisar responder ao remetente.
• Porta de destino  – a porta do dispositivo que recebe os dados. Os números da porta UDP podem estar entre 0 e 65.535.
• Comprimento  – especifica o número de bytes compreendendo o cabeçalho UDP e os dados de carga útil UDP. O limite para o campo de comprimento UDP é determinado pelo protocolo IP subjacente usado para transmitir os dados.
• Checksum  – O checksum permite que o dispositivo receptor verifique a integridade do cabeçalho do pacote e da carga útil. É opcional no IPv4, mas tornou-se obrigatório no IPv6

TCP vs UDP: quais as principais diferenças entre esses protocolos?

O UDP é mais rápido, mas menos confiável do que o TCP, outro protocolo de transporte comum. Em uma comunicação TCP, os dois computadores começam estabelecendo uma conexão por meio de um processo automatizado denominado ‘handshake’. Somente depois que esse handshake for concluído, um computador realmente transferirá pacotes de dados para o outro.

As comunicações UDP não passam por esse processo. Em vez disso, um computador pode simplesmente começar a enviar dados para o outro:

Além disso, as comunicações TCP indicam a ordem em que os pacotes de dados devem ser recebidos e confirmam se os pacotes chegam conforme o planejado. Se um pacote não chegar — por exemplo, devido a congestionamento em redes intermediárias — o TCP exige que ele seja reenviado. As comunicações UDP não incluem nenhuma dessas funcionalidades.

Quais as vantagens e desvantagens do UDP?

O UDP tem vários benefícios para diferentes tipos de aplicativos, incluindo:

• Sem atrasos de retransmissão  — UDP é adequado para aplicativos sensíveis ao tempo que não podem pagar atrasos de retransmissão para pacotes perdidos. Os exemplos incluem Voice over IP (VoIP), jogos online e streaming de mídia.
• Velocidade  — a velocidade do UDP o torna útil para protocolos de resposta a consultas, como DNS, nos quais os pacotes de dados são pequenos e transacionais.
• Adequado para broadcasts  — a falta de comunicação ponta a ponta do UDP o torna adequado para broadcasts, em que os pacotes de dados transmitidos são endereçados como recebíveis por todos os dispositivos na Internet. As transmissões UDP podem ser recebidas por um grande número de clientes sem sobrecarga do lado do servidor.
•  
•  
•  
• Desvantagens do protocolo de datagrama do usuário

•  1. Sem conexão

  UDP é sem conexão, o que significa que não requer necessariamente um circuito virtual antes do processo de transferência de dados. Portanto, sem qualquer preparação ou negociação, o grama de dados pode ser enviado ao receptor. O receptor deve ser capaz de cuidar deles.

  2. Não confiável

  UDP geralmente não é confiável porque não há nenhum conceito de retransmissão, reconhecimento ou tempo limite aqui. Sempre que um grama de dados é enviado, não é possível garantir que será entregue ao host de destino. Às vezes, o grama de dados pode ser perdido no caminho ou entregue duas vezes. A pior parte é que não há sequer uma indicação disso, a menos que o anfitrião decida mencioná-los. No entanto, esses tipos de taxas de falha são muito baixas em conexões de rede.

  3. Pedido incorreto

  Além de os dados não serem entregues, também podem estar fora de serviço no UDP. Não é possível garantir que a sequência em que os dados estão sendo enviados esteja na mesma ordem ao chegar ao aplicativo host. Às vezes, os pacotes podem ser ordenados de forma que você receba primeiro um pacote que foi enviado com atraso. Além disso, não há como prever esses pedidos até que sejam recebidos.

  4. Sem controle de congestionamento

  Ao contrário do TCP, os métodos de controle de congestionamento não estão presentes no UDP. Como não há nenhum método de controle de congestionamento no UDP, um grande número de dados transmitidos via UDP pode causar congestionamentos. Para isso, não há restrições que possam ser impostas.

  5. Suporte para roteador

  No que diz respeito ao tratamento do UDP, os roteadores são bastante descuidados. Isso ocorre porque sempre que um grama de dados é colidido, ele não os retransmite. Além disso, em um roteador os pacotes UDP serão descartados antes mesmo dos pacotes TCP.

Referencia: 

SEABRA, Giulianna. O que é UDP e quais as diferenças com o TCP?. In: O que é UDP e quais as diferenças com o TCP?. [S. l.], 19 jun. 2019. Disponível em: https://blog.betrybe.com/desenvolvimento-web/udp-diferencas-tcp/. Acesso em: 23 jun. 2022.

[ID:74] Autor:Higor da Silva Soares - Criado em: 2022-04-29 17:42:06 - [ Compartilhar ]

As salas limpas em indústrias farmacêuticas são importantes para elaboração de produtos de forma mais higiênica, para isso se faz necessário um controle de alguns parâmetros específicos como, a umidade de ar, a temperatura ou fluxo ar.

O projeto visa a criação de um protótipo de uma sala limpa com o monitoramento remoto e a gestão dos principais parâmetros que a envolvem como, a temperatura e a umidade do ar.

• SMART 1: Desenvolver um sistema de aquisição de dados;
• SMART 2: Construir um protótipo de uma sala limpa;
• SMART 3: Implementação dos principais dados via microcontrolador ESP32;
• SMART 4: Exercer o relatório do projeto;
• SMART 5: A construção do circuito controlador.

O sistema de detecção dos parâmetros serão aplicados em um ambiente fechado com uso de uma caixa de acrílico para fase de teste e finalização do projeto.

[ID:73] Autor:Breno Veronesi Miatello - Criado em: 2022-04-29 17:14:37 - [ Compartilhar ]

A escolha do projeto se deu devido a indecisão ou desconhecimento do uso de protetores auriculares no ambiente de indústria. E também a necessidade de se ter um sistema para uso em sala de aula que identifique aumento de ruídos evitando possíveis perturbações sonoras principalmente em autistas.

Os objetivos do projeto são:

• SMART 1: Identificar índices de ruídos relacionados a cada área;
• SMART 2: Simular o sistema eletrônico em ambiente virtual;
• SMART 3: Desenvolver um sistema de aquisição de dados;
• SMART 4: Construir um protótipo do sistema de detecção sonoro;
• SMART 5: Testar o protótipo em ambiente real

O sistema de detecção de ruídos será aplicado em ambiente fechado em um primeiro momento (fase de testes de funcionamento) e posteriormente em um ambiente real.

[ID:72] Autor:Beatriz Miano Paulino - Criado em: 2022-04-29 17:05:32 - [ Compartilhar ]

Planejamento

A escolha do projeto se deu devido a indecisão ou desconhecimento do uso de protetores auriculares no ambiente de indústria. E também a necessidade de se ter um sistema para uso em sala de aula que identifique aumento de ruídos evitando possíveis perturbações sonoras principalmente em autistas.

Os objetivos do projeto são:

• SMART 1: Identificar índices de ruídos relacionados a cada área;
• SMART 2: Simular o sistema eletrônico em ambiente virtual;
• SMART 3: Desenvolver um sistema de aquisição de dados;
• SMART 4: Construir um protótipo do sistema de detecção sonoro;
• SMART 5: Testar o protótipo em ambiente real

O sistema de detecção de ruídos será aplicado em ambiente fechado em um primeiro momento (fase de testes de funcionamento) e posteriormente em um ambiente real.

Concluido

Sistema de Detecção de Ruído Sonoro

O presente projeto tem como objetivo desenvolver um sistema eletrônico que possa detectar alterações de ruídos sonoros pré-determinados em ambientes industriais e escolares, com o intuito de obter um lugar mais seguro, agradável e produtivo.

O sensor utilizado é um Microfone Omnidirecional INMP441 (Figura 1), capaz de captar som em todas as direções, além disso já conta com um conversor analógico para digital e um filtro antialiasing, o qual permite a passagem de todas as frequências corretas, cortando as indesejáveis.

Figura 1 - Sensor Microfone Omnidirecional INMP441

Por meio de uma programação, os dados obtidos são tratados e armazenados no microcontrolador ESP32 (Figura 2), que possui um módulo WIFI e um módulo Bluetooth de comunicação integrados ao seu chip. A comunicação com o protocolo MQTT é feita usando a comunicação WIFI da ESP32.

Figura 2 - Microcontrolador ESP32

Para sinalizar visualmente quando o limite de ruído em decibéis é ultrapassado utiliza-se um Led vermelho. Logo, o circuito para obtenção de dados usado no projeto pode ser visto na Figura 3 e a montagem final do projeto na Figura 4.

Figura 3 - Circuito para obtenção de dados

Figura 4 - Montagem final projeto

Para a comunicação com o MQTT foi necessário alugar um servidor no AWS para fazer o armazenamento das informações no banco de dados, que são enviados para o MQTT pela ESP32. O banco de dados utilizado nesse servidor da AWS foi o Mysql, que tem a função de salvar os dados enviados para o MQTT na nuvem. Esses dados são exibidos na web, por meio de um IP público gerado pela instância AWS.

Por meio do Node-RED, uma ferramenta de desenvolvimento baseada em fluxos para programação visual em nós, ou em blocos, foi desenvolvida uma programação (Figura 5) que faz uma demonstração gráfica dos dados obtidos e as apresenta numa página da web (Figura 6).

Figura 5 - Programação Node-RED

Figura 6 - Representação gráfica dos dados coletados

Nas Figuras 4 e 6 é possível ver o Led acesso, já que o limite de ruído estipulado em 70dB foi ultrapassado, emitindo assim o alerta visual.

[ID:71] Autor:Jhonatas Wendell da Silva - Criado em: 2022-04-29 16:25:24 - [ Compartilhar ]

A irrigação é um método muito utilizado pela agricultura na produção de alimentos, mas enfrenta alguns problemas principalmente em grandes áreas de plantio, como a dificuldade em detectar falhas na tubulação como vazamentos, quebras ou mal funcionamento dos aspersores, outro problema encontrado é o controle de umidade do solo, tendo em vista que a falta ou excesso de água pode causar danos a produção.  

Integrar tecnologia ao sistema de irrigação, como a implementação de um sistema de monitoramento, permite que o agricultor acompanhe o desenvolvimento da plantação e tenha um controle maior sobre os desperdícios e gastos desnecessários. O monitoramento permite mensurar a umidade do solo, a pressão da água nas tubulações, temperatura e umidade relativa do ar, o que possibilita detectar o problema com rapidez, assim o agricultor pode evitar gastos de energia programando os dispositivos elétricos para atuarem somente quando necessário, e com o sistema de alerta de falhas os desperdícios de água e fertilizantes, em casos de fertirrigação, podem ser reduzidos. 

[ID:70] Autor:Mateus Cordeiro dos Santos - Criado em: 2022-04-29 12:25:55 - [ Compartilhar ]

A irrigação é um método muito utilizado pela agricultura na produção de alimentos, mas enfrenta alguns problemas principalmente em grandes áreas de plantio, como a dificuldade em detectar falhas na tubulação como vazamentos, quebras ou mal funcionamento dos aspersores, outro problema encontrado é o controle de umidade do solo, tendo em vista que a falta ou excesso de água pode causar danos a produção.  

Integrar tecnologia ao sistema de irrigação, como a implementação de um sistema de monitoramento, permite que o agricultor acompanhe o desenvolvimento da plantação e tenha um controle maior sobre os desperdícios e gastos desnecessários. O monitoramento permite mensurar a umidade do solo, a pressão da água nas tubulações, temperatura e umidade relativa do ar, o que possibilita detectar o problema com rapidez, assim o agricultor pode evitar gastos de energia programando os dispositivos elétricos para atuarem somente quando necessário, e com o sistema de alerta de falhas os desperdícios de água e fertilizantes, em casos de fertirrigação, podem ser reduzidos. 

[ID:69] Autor:Lorena Maria Costa do Nascimento - Criado em: 2022-04-29 10:25:32 - [ Compartilhar ]

Esquema da programação em blocos no Node-RED:

Módeulo GPS e ESP32 em uso:

Página web e node dashboard demonstrando a localização plotada no mapa, eletropostos ao redor, comparação de autonomia e rotas para o local:

[ID:64] Autor:Julia Maria Massareli Costa - Criado em: 2021-07-13 22:20:42 - [ Compartilhar ]

INTRODUÇÃO

A possibilidade de utilização da radiação solar como fonte de energia é conhecida desde o século XIX (TREVELIN, 2014). No entanto, em função da escassez de combustíveis fósseis e seu possível esgotamento futuro, a necessidade de se utilizar fontes renováveis de energia tem crescido exponencialmente nas últimas décadas.

 No Brasil, a adoção do uso de energia solar em grande escala ainda é recente. A geração de energia solar fotovoltaica correspondeu a 1% da oferta de energia elétrica do país em 2019, proporcionada por um aumento na capacidade instalada de 675 MW em usinas centralizadas e 1430 MW em micro e mini produções (Empresa de Pesquisa Energética, 2020).

Mesmo que essa participação corresponda a apenas uma pequena parcela da oferta de energia, a rapidez na difusão da tecnologia é alta. Ainda segundo os balanços energéticos da Empresa de Pesquisa Energética (2020), só em 2019 a geração solar cresceu em 92,2% em relação a 2018, seguindo tendências dos anos anteriores.

Esse crescimento da demanda tem proporcionado diminuições relevantes nos custos para implementação de sistemas fotovoltaicos, como se pode observar nos leilões de energia elétrica do país (EMPRESA DE PESQUISA ENERGÉTICA, 2017, 2018, 2019). Com essa expansão, o Brasil tem se tornado competitivo no mercado fotovoltaico, e apresenta grande potencial para investimentos na área.

Além de ser uma economia emergente e que incentiva o uso de fontes energéticas renováveis para produção elétrica, a localização geográfica do Brasil o torna um local propício para investimentos em energia solar. De acordo com Agência Nacional De Energia Elétrica (2005), o país, por ter grande parte de seu território próximo da linha do Equador, tem poucas variações na duração solar do dia e recebe uma quantidade significativa de radiação. Dessa forma, se torna importante entender o funcionamento de práticas de melhoria na eficiência energética de placas solares fotovoltaicas e o comportamento desses painéis em diferentes situações.

 OBJETIVOS

 Objetivo geral

            Gerar energia elétrica a partir de uma fonte solar fotovoltaica e monitorar a eficiência do sistema de geração energética.

 Objetivos específicos

• alimentar uma carga com a energia convertida de uma placa solar fotovoltaica

• elaborar um circuito de medição de parâmetros como tensão e corrente fornecidos pela placa

• elaborar programação para obtenção e tratamento dos dados recebidos

• montar banco de dados e página web para monitoramento do projeto

• acompanhar e analisar eficiência da placa conforme potencial solar da região.

MATERIAIS E MÉTODOS

Para a realização deste projeto, serão utilizados principalmente os seguintes componentes:

• placa fotovoltaica de 10 W;

• módulo ESP32 NodeMCU;

• fusível 0,6 a;

• capacitor 2200 uF;

• regulador 7812;

• regulador 7833;

• sensor de corrente ACS712;

• amplificadores operacionais;

• conversor AD MCP3202;

• lâmpada 12 V, 2 W.

Com esses componentes, o circuito básico será montado para a execução do projeto conforme a Figura 1.

Fonte: própria autoria.

O circuito será alimentado pela placa solar com uma tensão que varia de 19V a 20V quando exposta ao sol. 

A placa deverá ficar exposta ao sol em local sem sombras, posicionada em direção ao norte e com uma inclinação referente à latitude da cidade.

Para o circuito de carga, serão utilizados componentes como um fusível, um capacitor e reguladores 7812 e 7833. O objetivo desses componentes é fazer a proteção do circuito e a regulagem da tensão que a carga irá receber. A tensão gerada pela placa irá alimentar uma lâmpada de 12 V e o microcontrolador ESP32, que funciona com uma tensão de entrada de 3,3 V (ESPRESSIF SYSTEMS, 2021).

Um sensor de corrente ACS712 que realiza medição a partir do efeito Hall será utilizado para as medições. Para além do circuito básico, em função da melhoria da resolução do sinal obtido, poderão ser incrementados ao circuito amplificadores operacionais 741 e um conversor AD MCP3202, além de divisores de tensão para obtenção dos valores de tensão gerados pela placa. O sinal amplificado será enviado ao ESP32.

O módulo ESP32 (figura 3) terá a função de fazer a obtenção e tratamento dos dados solicitados. Uma programação será elaborada para calcular os valores proporcionais de tensão (V), corrente (A) e potência (W) sobre as leituras obtidas, enviar esses dados via Wi-Fi para uma plataforma de análise e armazená-los em um banco de dados. A partir do ESP32, um web-server para acesso local pela internet também será criado.

Já a plataforma de acesso remoto será realizada com base na utilização de máquinas virtuais do Amazon Web Service (AWS). Um web-server será criado a partir de uma instância do tipo EC2 (Amazon Elastic Compute Cloud) (AMAZON WEB SERVICE, 2021), com o auxílio do software Visual Studio Code e ferramentas de programação como o Node-RED (MICROSOFT, 2021; OpenJS Foundation, [2021]). 

Dentre algumas análises na prática com o projeto, figura 3, a dashboard mostrou os dados da tensão de forma satisfatória, figura 2. 

Figura 2. Dashboard do projeto.

Fonte: própria autoria.

Figura 3. Projeto na prática.

Fonte: própria autoria.

Esse projeto utiliza o software de programação em blocos, Node-Red e de uma interface de nível (Figura 4). No software foi utilizado comunicação por Message Queuing Telemetry Transport (MQTT), protocolo de mensagens  para sensores e dispositivos móveis para redes IP, que é responsável pela transmissão entre os dados dos sensores, como corrente, tensão que foi o objetivo desse trabalho, junto com o microcontrolador ESP32 e Node-Red (Figura 5).

Figura 4. Interface gráfica do aplicativo Node-RED

Fonte: própria autoria.

Foi feito uma melhoria na dashboard para a  leitura dos dados como a corrente, tensão e potência (Figura 5).

Figura 5.  Interface dos dados da placa solar.

Fonte: própria autoria.

RESULTADOS E DISCUSSÕES

Feito o projeto, é possível fazer análise de que precisa-se melhorar o circuito, pois faltou componentes e houve instabilidade no sensor de corrente. Com isso, foi possível analisar somente a tensão em que a placa fotovoltaica se encontrava, com o não funcionamento do sensor de corrente, não foi possível gerar a potência. Pretende-se melhorar o circuito para obter melhores resultados, e também aprofundar no projeto construindo um protótipo de rastreador solar. Como o circuito não funcionou, foi construído um circuito utilizando um potenciômetro, para analisar o funcionamento da dashboard. Com isso, foi possível analisar conforme aumentava e diminuía o potenciômetro.

[ID:63] Autor:Ana Beatriz Valentin - Criado em: 2021-07-07 19:37:01 - [ Compartilhar ]

O presente projeto utiliza-se do software de programação Node-Red e de uma interface gráfica (Figura 1) que o próprio software oferece. No software foi utilizado nodos de comunicação por Message Queuing Telemetry Transport (MQTT), protocolo de mensagens leve para sensores e pequenos dispositivos móveis otimizado para redes TCP/IP, que é responsável pela transmissão entre os dados dos sensores (temperatura, corrente elétrica e fluxo de água), aquisitados pelo microcontrolador ESP32 WROOM-32, e o Node-Red (Figura 2).

Figura 1 - Interface gráfica do aplicativo Node-RED

Fonte: Autoria Própria

Figura 2 - Nodos responsáveis pela comunicação via dupla entre o Node-RED e o microcontrolador (em violeta) e sua impressão na interface gráfica

Fonte: Autoria Própria

O Node-RED e o MQTT também foram utilizados para a comunicação entre o aplicativo Telegram e o software Node-RED. O bot do Telegram (Figura 3) é privado e tem as seguintes funções: o repasse do link do dashboard da interface gráfica (citada acima), a definição da temperatura máxima e mínima do intervalo de temperaturas (definido pelo operador via Telegram e enviado via MQTT para o Node-RED e ESP32),a verificação do valor de temperatura atual, a verificação do intervalo de temperaturas atual e o envio de mensagens ao operador quando a temperatura está fora desse intervalo (Figura 4). Os nodos do Node-RED responsáveis pelo funcionamento do bot do Telegram são representados na Figura 5. 

Figura 3 - Bot Telegram e suas funções

Fonte: Autoria Própria

Figura 4 - Aviso de saída do intervalo de temperaturas do bot do Telegram

Fonte: Autoria Própria

Figura 5 - Nodos responsáveis pelo funcionamento do bot do Telegram

Fonte: Autoria Própria

Por fim, foi utilizado um banco de dados MySQL para o armazenamento das variáveis do horário da leitura, da leitura atual de temperatura, da temperatura máxima e mínima. Os útlimos dez dados armazenados no banco foram impressos na interface gráfica na forma de tabela (Figura 6) e os nodos responsáveis pela leitura e escrita do banco de dados MySQL é são representados na Figura 7. 

Figura 6 - Tabela com os últimos dez valores de leitura 

Fonte: Autoria Própria

Figura 7 - Nodos responsáveis pela leitura e escrita do banco de dados MySQL

Fonte: Autoria Própria

[ID:62] Autor:Francisco Garcia Braghini - Criado em: 2021-07-07 19:34:26 - [ Compartilhar ]

Metodologia e Aplicações de Uma Bancada De Reabilitação de Joelho 

O presente projeto tem como objetivo a aquisição de dados de um de uma bancada de reabilitação de joelho por meio de sensores para acesso remoto para epara o acompanhamento de possiveis falhas na execução do movimento ou acompanhamento da melhora corporal, facilitando o acomanhaento do fisioterapeuta especializado, para a aprimoramento semanal do protocolo de reablitação, tendo em vista efetuar uma melhor apresentação do IHM para o fisioterapeuta e trazer uma tecnologia mais atual e concreto.

Para realizar esse projeto, é preciso estabelecer objetivos específicos:

• Criar uma instância EC2 na Amazon Web Services (AWS);
• Instalar Apache, MySQL e PHP na instância;
• Criar um RDS na AWS e configurar ele através do MySQL;
• Instalar o Node-RED na instância EC2;
• Utilizar o protocolo MQTT no Node-RED e no microcontrolador (Esp32);
• Construir uma interface dashboard através do Node-RED para que o usuário possa realizar o controle e visualizar os dados pela mesma;
• Integrar o banco de dados RDS no Node-RED;
• Desenvolver o circuito e integrar o Esp32;
• Aplicar o sistema na bancada de joelho;

O respectivo trabalho consta como um complemento do TCC do aluno Vinícius Bizache Cruz  sobre "Melhoria do protopito de aparelho CPM para reabilitação de joelho ". 

O sensor simulado para o projeto foi o encoder incremental, que apresenta uma alimentação em de 5 à 24Vcc, tendo uma resolução de 600 pulsos por rotação. A figura 1 representa o enconder 

                                                      FIGURA 1. Enconder 

                                                      fonte: proprio autor 

Os dados serão coletados utilizando o ESP32 (Figura 2) e armazenados em uma database.

                                                                            FIGURA 2. ESp 32

                                                                fonte: proprio autor 

Para visualizar os dados lidos pelo sensor, foi elaborado um dashboard por meio da ferramenta Node-Red. Foi utilizado também o editor de código-fonte Visual Code para elaborar a programação, bem como uma máquina virtual, para possibilitar a comunicação.observada na figura 3 abaixo.

                                                                            FIGURA 3. node red 

                                                    fonte: proprio autor 

Na interface desenvolvida pode-se observar graficos e indicadores das variaveis para facilitar a visualização. A figura 4 representa  a dashboard elaborada. A mesma apresenta um comando de armazenamento de bancos de dados. 

                                                 FIGURA 4. dashboard

                                                                   fonte: proprio autor 

[ID:61] Autor:Vinicius Bizache Cruz - Criado em: 2021-06-17 13:18:16 - [ Compartilhar ]

O presente projeto tem como objetivo geral a integração dos dados de acionamento dos ar-condicionado do Instituto Federal de São Paulo no campus de Catanduva, para que o usuário tenha acesso as informações por uma interface web. Para atingir esse resultado o projeto é dividido em etapas, considerando-as como objetivos específicos a ser atingido ao decorrer do desenvolvimento do projeto.

• AWS
• APACHE / PHP / Mysql
• Node-Red
• MQTT

Para a aquisição de dados dos status dos dispositivos, é usado um microcontrolador ESP32, demonstrado na figura 1, na qual possui uma placa wireless, que facilita a comunicação remota. O ESP32 realiza a coleta dos dados e através do protocolo MQTT que tem a função de efetuar a comunicação entre os dispositivos IOT. Após a aquisição dos dados é enviado as informações para um brocker. Para acessar essas informações é utilizado o Node-RED que é uma ferramenta visual de ambiente que permite conectar dispositivos e mostrar ao usuário as informações via web services. Com os dados já disponíveis no Node-Red, será criado um banco de dados para salvar as alterações que os ar-condicionado tiveram com o ligamento e desligamento. No node-red é criado um template para que o usuário possa visualizar as informações de. Os dados armazenados no mysql também poderão ser consultados na Dashboar podendo visualizar os horários e em que salas o dispositivo foi utilizado.

Figura 1 - Esp32

O projeto será desenvolvido em um servidor virtual no sistema operacional Ubuntu 20.04 utilizando os serviços do aws. Para a instalação do serviço foi utilizado os passos descritos no link:.

Após a criação da instância, foi realizado a instalação de um servidor HTTP Apahce, php e mysql. Para a instalação foi realizado o tutorial descrito no site da Digital Ocean: .

Após a instalação dos passos descritos anteriormente, foi criado um banco de dados nomeada de “horários”, e dentro dela foram criadas tabelas apresentadas na figura 2, que é designado a cada sala do Campus Catanduva e dentro das tabelas são salvas as informações de dia e horário que houve a alteração do estado do ar-condicionado.

Figura 2 - Tabela Sala01

Fonte: Autor

 Com a criação de um banco de dados, o próximo passo foi instalar um broker MQQ no Ubuntu, um intermediário entre máquinas e os protocolos. Ele é utilizado no protocolo MQTT para fazer com que os aparelhos possam conversar entre si e agir de maneira automatizada. O broker utilizado foi o Mosquitto pela facilidade na instalação, compatível com vários tipos de maquinário. Para a instalação do broker, foi utilizado o tutorial disponível em: . Mesmo com o tutorial apresenta ensina a instalar no Ubuntu na versão 16.04, os passos descritos também funcionaram corretamente na versão do Ubuntu utilizado nesse projeto.

Com o projeto em desenvolvimento, a primeira parte de trabalho realizado no Node-Red foi o desenvolvimento de um template básico ilustrado na figura 3, para mostrar visualmente o acionamento do ar-condicionado. Foi utilizado botão de acionamento, que simula o ligamento/desligamento dos ar-condicionado, e a mensagem de mudança do estado do botão é enviado via MQTT e o led é acionado dependendo da condição do botão.

Figura 3 - Template

Fonte: Autor

 Após isso a próxima etapa é realizar a integração dos dados de mudança do estado dos ar-condicionado e salvar no banco de dados criado anteriormente para que o usuário possa consultar o histórico de acionamento dos dispositivos. Os dados são enviados do microcontrolador por meio do MQTT e recebido na plataforma node-red. A Figura 4 apresenta os nós utilizado para programação que insere os valores no banco de dados, onde os nós roxos são configurados para a recepção das informações, o nó function descrito como INSERT tem a função de receber esses dados e inserir corretamente dentro do banco de dados (horários).

Figura 4 – Inserção dos valores no banco de dados

Fonte: Autor

Para o correto funcionamento do MQTT é necessário colocar as configurações do servidor utilizado e do topic que funciona como um endereço para o envio das informações. Nas configurações do servidor é necessário colocar o endereço IP e a porta 1883 onde é realizado a comunicação. Para que haja a comunicação também é necessário a liberação dessa porta no servidor que está sendo realizado o projeto. Para liberação dessa porta TCP é utilizado o seguinte comando:

• sudo ufw allow 1883

Com as configurações realizadas é feita a programação para a inserção de dados no banco como mostrado na figura 5. A primeira coisa a ser realizado é converter o tipo de dados enviado do mqtt de payload para topic na qual é o tipo de dado que é necessário para inserir os dados no banco.

Figura 5 – Programação para inserir os dados

Fonte: Autor

Para a utilização do banco de dados, foi necessária a instalação de um nó “node-red-contrib-stackhero-mysql”. Em suas propriedades é necessário colocar o Host que é o Ip/endereço onde o banco de dados se encontra, o User definido como o usuário cadastrado no banco de dados e sua senha no campo do password e por último a database criado no mysql.

Figura 5 – Configuração do banco de dados

Com a configuração do banco de dados e do nó Function já é possível receber os dados do mqtt e adicionar no banco de dados que possibilita o controle de tempo de acionamento dos ar-condicionado do instituto.

[ID:55] Autor:Marcos Vinicios dos Santos - Criado em: 2021-05-31 15:04:57 - [ Compartilhar ]

Introdução

Com a falta de chuvas que atinge grandes regiões espalhadas pelo mundo inteiro, é de grande importância pensarmos em soluções para aproveitar da melhor forma possível esse bem tão essencial para a vida, que é a água. Pensando nisso, é de suma importância que todos nós economizem água, principalmente em lavouras de plantação. Desta forma esse projeto proposto tem como objetivo, a implementação de um sistema de irrigação inteligente, onde a planta vai receber de água a quantidade adequada para seu desenvolvimento. O sistema de irrigação proposto se dá por meio de gotejamento, que será aplicada diretamente em cada planta, o que reduzira o consumo de água e também o desperdício. A fim de realizar a automação do processo de irrigação localizada, utilizará um módulo ESP32, baseado no conceito de IoT (Internet das Coisas), montando uma central controladora de fluxo de água através da junção de uma bomba submersa e sensores de temperatura e umidade. Dessa forma o projeto estará visando a sustentabilidade de pequenas áreas de cultivo, aumentando a eficiência do plantio e diminuindo perdas com recursos hídricos, tornando mais rentável o setor da agricultura. Esse projeto tem como objetivo principal desenvolver um sistema capaz de controlar o bombeamento de água, através da umidade do solo. Este circuito possuirá automatização em seus acionamentos.

A horta do campus é de fundamental importância, pois a mesma não conta com fins lucrativos, mas sim ser auto suficiente, oferecendo hortaliças, auxiliando numa alimentação balanceada para os alunos do campus.

Objetivo

Um led, deverá acender e logo em seguida, acionar a bomba submersa quando a umidade do solo indicar valor abaixo de 30%(trinta por cento), e apagar logo após a umidade atingir um valor superior ao minimo estabelecido.

Objetivo específico

O projeto tem como intuito principal o desenvolvimento de um código, utilizando a plataforma dashboar, e  aplicar para omitimização de uma horta que fica nas dependências do Instituto Federal, Campus Catanduva-SP. Tal horta, já conta com instalação de um sistema de irrigação automatizado em dois módulos agroflorestais. O sistema utiliza um microcontrolador Arduino que recebe a informação programada e ativa as válvulas de solenóide, acionadas por relés, ligando ou desligando a irrigação. Porém esse projeto que já está em andamento/funcionamento, encontra alguns desafios que por através deste projeto, espera se resolver. Um dos problemas mencionado por um servidor do campus, é e que o atual sistema com Arduino, precisa ser reprogramado frequentemente. Então esse trabalho propõe que essa alteração possa ser feita remotamente pela dashboard.

Matérias e Métodos.

Nesse trabalho usaremos um microcontrolador ESP32 cujo o mesmo apresenta-se como um meio inovador no desenvolvimento de projetos automatizados além do clássico módulo de comunicação Wi-Fi apresenta um sistema com processador Dual Core, Bluetooth híbrido e múltiplos sensores embutidos, tornando a construção de sistema como internet das coisas (IoT) muito mais simples e compacto.Usaremos também outros componentes eletrônicos e também desenvolver um código na plataforma Arduino que vai se cumunicar com a Esp32.

As características da placa são as seguintes:

• CPU: Xtensa® Dual-Core 32-bit LX6;
• Memória ROM: 448 KBytes;
• Clock máximo: 240MHz;
• Memória RAM: 520 Kbytes;
• Memória Flash: 4 MB;
• Wireless padrão 802.11 b/g/n;
• Conexão Wifi de 2.4Ghz (máximo de 150 Mbps);
• Antena embutida na placa;
• Conector micro USB para comunicação e alimentação;
• Wi-Fi Direct (P2P), P2P Discovery, P2P Group Owner mode e P2P Power Management;
• Modos de operação: STA/AP/STA+AP;
• Bluetooth BLE 4.2;
• Portas GPIO: 11;
• GPIO com funções de PWM, I2C, SPI, etc;
• Tensão de operação: 4,5 ~ 9V;
• Conversor analógico digital (ADC).

Sensor DHT11

É um sensor de umidade e temperatura que permite fazer leituras de temperaturas entre 0 a 50 Celsius e umidade entre 20 a 90%

As características do sensor DHT11 são as seguintes:

• Faixa de medição de umidade: 20 a 90%
• Faixa de medição de temperatura: 0° a 50°C
• Alimentação: 3-5VDC (5,5VDC máximo)
• Corrente 200uA a 500 mA
• Precisão de umidade de medição: +/- 5,0% UR
• Precisão de medição de temperatura: +/-2.0 °C
• Tempo de resposta: 2s
• Dimensão: 23x12x5mm (incluindo os terminais)

Sensor de umidade do solo higrômetro

É um sensor feito para detectar as variações de umidade no solo, sendo que quando o solo está seco a saída do sensor fica em estado alto, e quando úmido em estado baixo.

As características do sensor  são as seguintes:

• Tensão de operação: 3,3-5v
• Sessibilidade ajustável via potenciômetro
• Saída digital e analógica
• Fácil instalação
• Led indicador para tensão (vermelho)
• Led indicador para saída digital (verde)
• Comparador LM393
• Dimensões PCB 3x1,5cm
• Dimensões sonda 6x2cm
• Comprimento cabo 21cm

Bomba Submersa

São bombas de recalque de elevado rendimento, concebida para circulação ou bombeamento de água em tanques, aquários ou lagos. Uma das maiores vantagens é que ela pode ser utilizada tanto em água doce quanto salgada devido ao seu impeller de cerâmica que evita corrosão. Ela é facilmente desmontável, permitindo que manutenções rotineiras sejam extremamente mais fáceis, evitando qualquer problema na bomba, como um impeller obstruído ou até mesmo danificado.

As caracteristicas da bomba submersa são:

• Alta eficiência com baixo consumo energético
•  Elevada vazão e coluna d'água
•  Impeller em cerâmica, que permite uso em aquários de água doce ou salgada
•  Corpo resistente construído em plástico ABS
• Tela de proteção que evita que peixes entrem na bomba, assim como maiores resíduos que possam danificar o impeller
• Indicada para sumps, lagos, cascatas e fontes
• Fácil montagem e desmontagem para manutenções preventivas
•  Suporte com fortes ventosas, que evitam que a bomba se movimente
•  Acompanha kit de conexões

Parte do código

#include
#include
#include
#include "DHT.h"
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"

#define DHTPIN 4 
#define DHTTYPE DHT11

const char* ssid = "Flamengo";
const char* password = "997565941";

const char* mqtt_server = "henriqueifsp.duckdns.org";

DHT dht(DHTPIN, DHTTYPE);
WiFiClient espClient;
PubSubClient client(espClient);

const int bomba = 26;
const int bomba2 = 32;
const int umidade = 34;

long lastMsg = 0;
char msg[50];
int value = 0;
float h, hu, t;

//*****************************************************
void setup() {
  Serial.begin(115200);
  dht.begin();
  setup_wifi();
  client.setServer(mqtt_server, 1883);
  //client.setCallback(callback);
  //xTaskCreate(leumidade_task, "le umidade", 5000, NULL, 3, NULL);
  xTaskCreate(letemperatura_task, "le temperatura", 5000, NULL, 4, NULL);
  pinMode (bomba, OUTPUT);
  pinMode (bomba2, OUTPUT);
}

Conclusão

Apesar das dificuldades encontradas devido a pandemia da COVID-19, o resultado foi satisfatório e o projeto atendeu o propósto inicial. Embora não tenha sido possível uma aplicação física do protótipo na horta do campus, os acionamentos funcionaram perfeitamante e o código que foi desenvolvido poderá ser utilizado futuramente para a continuidade de implementação da irrigação na horta do campus.

[ID:54] Autor:Henrique da Silva - Criado em: 2021-05-26 15:13:33 - [ Compartilhar ]

Sugestões para se capacitar em Node-Red

[1]  Desenvolvimento de aplicações integrando serviços Web, fontes de dados e dispositivos IoT com o uso do Node-RED. Ministrantes: Celso Alberto Saibel Santos e Jordano Ribeiro Celestrin  (pdf)  (github). Curso USP com reposítório e exemplos básicos json.

[2] Curso Udemy de Reginaldo Santos. Do Zero ao Node-Red (Prototipagem rápida). Assista ao curso liberado no Canal Youtube do Autor [playlist youtube] [aula 1-4 som editado]  (Seção 7 Front End )

( Seção 8 Construindo Estação )

[3] HowTo: Node Red – Creating a User Interface with Dashboard Nodes

[4] Slide aplicaões: https://sesam-world.com/_pdf/sesam-134/05-IBM.pdf

[5]  Passe, Fernando et al . Perspectivas para o uso do Node-Red no Ensino de IoT

[6]  da Silva, Esdras Barbosa Lima J.  Node-RED KNoT: Um módulo de integração da ferramenta Node-RED com a meta plataforma KNoT

[ID:50] Autor:Marcos Aparecido Chaves Ferreira - Criado em: 2021-05-17 23:32:34 - [ Compartilhar ]

O Protocolo Mqtt permite a comunicação entre os dispositivos para Internet das Coisas.

Teoria:  Link 1, link 2

O seguinte tutorial, embora explica como instalar um broker Mosquitto no Ubuntu, sendo realizado os testes na instância Ubuntu cloud AWS.

Referência: https://www.vultr.com/docs/how-to-install-mosquitto-mqtt-broker-server-on-ubuntu-16-04

$ sudo apt-get update
$ sudo apt-get install mosquitto

$ sudo apt-get install mosquitto-clients

Habilite o redirecionamento de portas utilzando ufw

$ sudo apt install ufw
$ sudo ufw allow 1883
$ sudo ufw allow 22
$ sudo ufw enable

Para testar mensagem assine (subscribe o tópico "test"

$ mosquitto_sub -t "test"

Publicando mensagem:

mosquitto_pub -m "message from mosquitto_pub client" -t "test"

Para segurança do broker, permita conexão apenas de usuários com senha. Crie o scrpit:

$ sudo nano /etc/mosquitto/conf.d/default.conf

Preencha o arquivo com o seguinte texto:

allow_anonymous false
password_file /etc/mosquitto/passwd

Execute o comando:

$ sudo systemctl restart mosquitto

Configure senha para o usuário por exemplo "dave"

$ sudo mosquitto_passwd -c /etc/mosquitto/passwd dave
Password: password

Reinicie a instância e repita os testes:

$ mosquitto_sub -t "test" -u "dave" -P "password"

$ mosquitto_pub -t "test" -m "message from mosquitto_pub client" -u "dave" -P "password"

O MQTT.fx é um Software Cliente versão Windows, onde é possivel testar protocolo MQTT. Com ele é possível publicar e assinar tópicos.

https://mqttfx.jensd.de/index.php/download

Existem diversos aplicativos para celular, utilizar o protocolo mqtt para suas aplicações IOT. O aplicativo android: MQTT Dash é muito simples de operar.

IOT com Smarphone

Este projeto da IBM, descreve uma aplicação de ensaios utilizando o giroscópio do celular como sensor IOT enviando para o Broker público HiveMQ

https://developer.ibm.com/tutorials/iot-mobile-phone-iot-device-bluemix-apps-trs/

Utilizando Arduino com MQTT

Enviando valores através de mensagens no formato Json para um broker mqtt

Utilize a biblioteca para implementar o serviço mqtt em exemplos com Arduino. A bilioteca oferece funções para leitura e publicação de mensagens em formato Json. O seguinte exemplo mostra uma função que prepara uma mensagem Json para ser publicada no broker.

Links:

[1] Utilizando MQTT com Node Red

[2] Video aula Teams, apresentando o MQTT.

[ID:48] Autor:Marcos Aparecido Chaves Ferreira - Criado em: 2021-05-11 18:28:53 - [ Compartilhar ]

                                                                  Fonte:  PyImageSearch

Em meio a pandemia de coronavírus diversas medidas foram criadas para conter o avanço da doença, uma dessas o uso obrigatório de máscaras em diversas regiões. Este projeto consiste em um sistema de controle de acesso autônomo IOT com detecção de uso de máscara e temperatura corporal, que tende a fazer o controle de acesso em locais fechados, permitindo a entrada de pessoas com máscara e temperatura corporal estável, e não permitindo o acesso de pessoas sem máscaras (ou com máscaras utilizadas de forma inadequada ao rosto) e com temperatura corporal considerada febril. 

Os materiais a serem utilizados são: uma Raspberry Pi 4B, sensor de temperatura IR e câmera para fazer a detecção de máscara e por meio de Deep Learning com Computer Vision, a Raspberry Pi enviará dados para um webserver, que será responsável de fazer o controle de acordo com os parâmetros estabelecidos de acesso.

Espera-se que o sistema consiga liberar o acesso apenas de pessoas que estejam com uma temperatura estável e com o uso correto de máscara.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

I - Sistema de verificação de uso de máscara

Para se verificar o uso de máscara uma programação em Python é utilizada .

Primeiramente um dataset de 1376 imagens é utilizado para o aprendizado de máquina e está dividido em 2 classes:

• with_mask

  : 690 imagens

• without_mask

  : 686 imagens

Após a finalização da etapa de aprendizado , um modelo é gerado, este modelo é usado por outra programação responsável por transmitir a câmera com quadros de verificação de uso de máscara.

O as linhas de código abaixo são responsáveis de enviar a cada 5 segundos dados do sensor para uma API

Na imagem abaixo temos como fica a estrutura da API com o envio dos dados

 A estrutura anterior é requerida para o node-red e tratada como mostrado na imagem abaixo:

II - Sistema de verificação de temperatura

No sistema de temperatura o sensor envia os dados para uma DB MySQL que envia os dados mais recentes a uma página .php , este site .php é lido no Node-RED

Imagem do Dashboard finalizado:

Referências :

COVID-19: Face Mask Detector with OpenCV, Keras/TensorFlow, and Deep Learning - PyImageSearch

prajnasb/datas (github.com)

observations/mask_classifier at master · prajnasb/observations (github.com)

[ID:47] Autor:Wladerson Roman Rissi - Criado em: 2021-05-05 20:37:52 - [ Compartilhar ]

Node RED, é a principal ferramenta de programação para a internet das coisas.

Construída em node.js, utiliza programação gráfica através de blocos (conhecidos como nós) com funções predefinidas para a realiação de tarefas por meio de um fluxo (flows).

A programação é realizada por meio de browser com acesso a back-end do framework.

Ambiente de programação

Há basicamente três tipos de nós.

 nós de entrada (permitem que os dados sejam inseridos em uma aplicação),

nós de saída (permitem o envio de dados para fora de uma aplicação) e

nós de processamento (permitem a manipulação dos dados que entram nos mesmos afim de disponibilizar novos dados para o estágio posterior).

Há um vasta variedade de nós para as mais diversas aplicações possíveis instalados através do menu Manager.

Maiores informações sobre a aplicação e exemplos de códigos (flows) visite a pagina oficial: https://nodered.org

Para instalação do Node-red, sugerimos os seguintes links com tutorial. O primeiro link embora direciona para instalação em Debian, funcionou para instalação Ubuntu no AWS. A primeira etapa deve-se conectar com o servidor para utilizar os comandos prompt  de atualização de pacotes:

$ sudo apt-get update 

$ sudo apt-get upgrade -y

Passo 2: Instale NPM e NodeJS

Verificar versão instalada

Atualizar versão node

Há um pacote chamado n, que nos ajuda a alterar a versão do Node

Reinicie seu terminal para que as mudanças tenham efeito.

Instalando Node-red com npm

Node-red em linha de comando criando usuario admin

Script para adicionar o Node-red na inicialização ( link)

Debian:  Passos e respondendo as perguntas em cada passo: https://roveeb.com/post/como-instalar-o-node-red-como-um-servico-em-distribuicoes-baseadas-no-debian/

Para iniciá-lo toda vez que o sistema reiniciar, é necessário rodar o comando sudo systemctl enable nodered.service

O serviço Node-Red funcionará na porta 1880 de seu servidor. Edite as configurações de entrada no serviço AWS acrescentando a porta 1880. Utilize as orientações deste link (https://www.techunits.com/topics/setup-guides/step-by-step-guide-to-install-node-red-on-ubuntu-18-04-lts/)  para alocar a porta para este serviço.

Embora no final da instalação apareça um endereço de ip local (127.0.0.0), confira o serviço funcionando em http://(ip_seu_servidor):1880

Esta instalação porém não ativa uma senha para bloquear o acesso aos seus flows.

Para colocar uma senha de segurança de acesso aos flows.

https://nodered.org/docs/user-guide/runtime/securing-node-red

Instale o módulo de segurança como root (super usuário)

Crie uma senha para o login "admin"

Copie esta senha que será inserida no script de credenciais.

Acesse a pasta oculta

Edite o arquivo ainda com root

Localize o seguinte trecho no arquivo ./node-red/settings.js , para retirar os comentarios e cole a senha criptografada.

CRTL+X para salvar o arquivo. Reinicie o servidor utilizando o comando reboot ou a na área de administração das instâncias AWS.

Links:

[1] Video aula Teams Prof. Marcos Chaves.

[ID:45] Autor:Marcos Aparecido Chaves Ferreira - Criado em: 2021-05-05 00:55:05 - [ Compartilhar ]

O presente projeto tem por finalidade servir à comunidade desempenhando o papel de uma estação de controle climático, isso é, com armazenamento em nuvem. Em teoria, ele funcionará como um painel de estação meteorológica na nuvem que permitirá visualizar os registros do sensor utilizado, o ESP32, remotamente. Sensor irá solicitar o HTTP POST a um script PHP para a inserção dos dados em um banco (database) MySQL. O sensor permitirá mensurar a umidade e a temperatura, onde também ele estará conectado com um ar e um humidificador, onde você pode controlar a temperatura mínima e a temperatura máxima, quando chegar a temperatura máxima o ar condicionado ele é ativado e quando atingir a temperatura mínima ele é desligado, isso também funcionará com o humidificador, onde a o usuário irá defininir umaumidade relativa máxima e uma mínina e quando a leitura da umidade for igual a umidade relativa minima definida pelo usiário ela irá ligar o umidificadore quando atingir a umidade relativa máxima ela desligará, onde ttambém contém um botão onde o usuário poderia ligar manualmente o ar condicionado ou o humidificador. Em relação à construção do projeto será utilizado, incluso hardware e software, as tecnologias abaixo:

• ESP32 – Programado com Arduíno IDE
• Servidor de hospedagem + nome de domínio
• Script PHP para inserção de dados no MySQLe exibição em uma página web
• Banco de dados MySQL para armazenamento
• Node-Red
• aws
• apache/PHP
• MQTT

Será utilizado o sensor BME280 modelo capaz de realizar a medição de pressão atmosférica, umidade e temperatura, também conhecido como barômetro é um módulo digital de alta capacidade e resolução, utilizado nas mais diversas aplicações junto a microcontroladores, como por exemplo ESP32.

- Utilizado em projetos de estações meteorológicas e aperfeiçoamento de navegação GPS, ele apresenta grande potencial e mostra ser um produto de grande auxílio para projetistas que procuram um exclusivo produto capaz de executar as três funcionalidades principais sem ocupar muito espaço.

- Através de seu padrão de conexão por I2C, o sensor de Pressão BME280 aumenta a sua praticidade de utilização, além de contribuir na maior precisão da obtenção de resultados.

- Desenvolvido com base no sensor Bosh ME280, o Sensor possui design simplificado com pequenas dimensõe que tornam este pequeno módulo um produto de fácil adaptação nos mais diversificados projetos, além de contar com 2 exclusivos furos para melhorar a fixação do mesmo junto aos mais diversificados projetos.

CARACTERÍSTICAS:

- Sensor de Pressão BME280;
- Sensor de Umidade;
- Sensor de Temperatura;
- Produto pequeno de fácil utilização;
- Sistema de comunicação I2C;
- Compatível com diversos modelos de microcontroladores;

Sobre o módulo ESP32 que é utilizado no projeto ele é um módulo de alta performance para aplicações envolvendo wifi, contando com um baixíssimo consumo de energia. Com 4 MB de memória flash, o ESP32 permite criar variadas aplicações para projetos de IoT, acesso remoto, webservers e dataloggers, entre outros.

Foi utilizado no projeto que irá ser desenvolvido em um servidor virtual no sistema operacional Ubuntu 20.04 utilizando os serviços do aws. Para a instalação do serviço foi utilizado os passos descritos no link:.

Logo após a criação da instância, foi realizado uma instalação de um servidor HTTP Apahce, php e mysql. Para a instalação foi realizado o tutorial descrito no site da Digital Ocean: .

[ID:42] Autor:Sergio Lin - Criado em: 2021-05-04 18:15:13 - [ Compartilhar ]

INTRODUÇÃO

Nos últimos anos a produção agrícola brasileira tem-se desenvolvido constantemente em suas produções, podendo se tornar um dos grandes fornecedores de alimentos no futuro. Com a alta produção também se acarreta gasto energético e hídrico, que podem levar ao aumento do preço do produto. De acordo com o relatório O Estado da Alimentação e da Agricultura (SOFA) 2020, a agricultura irrigada corresponde a mais de 70% do uso de água no planeta, a qual nem sempre é utilizada da melhor forma, podendo haver desperdício devido ao mal uso e controle da irrigação. Em um relatório divulgado pela ONU, o uso de água tem crescido em uma taxa aproximadamente duas vezes maior do que o crescimento da população ao longo do último século. Todos esses gastos hídricos são atribuídos a má utilização dos métodos de irrigação do cultivo.

Segundo Coelho e Silva (2009), o conceito de Agricultura de Precisão é associado a utilização de tecnologia, sendo hardware e software, com o intuito de monitorar e controlar parcelas de terreno buscando a melhoria na produção e reduzir impactos ambientais resultantes das atividades agrícolas. Balafoutis, Van Evert e Fountas (2020) afirmam que as tecnologias ajudam a coletar e transmitir dados em tempo real a baixo custo, permitido realizar uma análise para determinar o estado do agroambiente e posteriormente aplicar intervenções técnicas no nível de campo por meios convencionais ou automatizadas para melhoria do processo.

A umidade é um dos fatores do solo que quando empregada sua análise e automatização apresenta diversos benefícios para agricultura, como por exemplo, a economia de água, a melhora nos rendimentos das plantas, a redução a dependência dos fertilizantes e a melhora na qualidade das culturas (Hassan-Esfahani et al., 2014). Um exemplo aplicado por Zotarelli et al. (2009), mostrou que plantios que utilizaram sensores de umidade no solo obtiveram uma taxa de 15 a 51% de redução da utilização de água na irrigação em comparação com irrigação de tempo fixo e observou um aumento de produtividade da safra ente 11 a 26% (apud Datta et al., 2018).

A determinação da quantidade de água que o solo é capaz de reter, está ligado com as características físico, químico e biológico do solo, podendo afetar a produtividade agrícola. A possibilidade de determinar a umidade do solo é de grande interesse para trabalhos de irrigação. Segundo Kaiser et al. (2010), a umidade do solo apresenta influência na porosidade e suscetibilidade à compactação do solo.

Klein (2008) destacou que existem diversos métodos e técnicas para determinação da umidade do solo, tendo principais diferenças entre eles a forma de medição, custo, tempo de resposta e operacionalidade em campo. Ele também afirma que o método de extração de água de uma amostra de solo por meio do calor utilizando-se estufas elétricas, é capaz de determinar a umidade gravimétrica do solo pela relação entre a massa de água e a massa do solo seco. Santos (2006) afirma que esse método é destrutivo, mas muito preciso, sendo utilizado como padrão de calibração para outros equipamentos.

Existem diversos tipos de sensores disponíveis, com desempenhos variáveis, uns medem o teor de umidade do solo, enquanto outros medem o potencial da água no solo e a constante dielétrica. Dentre eles tem-se sensores TDR e TDT, que são precisos, mas de alto custo para aplicação. Em contraste, os sensores de capacitância são mais baratos, mas requerem calibração para resultados de medição satisfatórios. A capacitância do sensor é determinada pela constante dielétrica e este sensor fornece dados de umidade do solo em tempo real de acordo com a variação. Visconti, Paz, Martínez e Molina (2014), descrevem que os sensores que buscam obter dados de umidade explorando propriedades dielétricas do solo, são relativamente baratos e flexíveis comparados aos sensores TDR e TDT. Atualmente existe diversos modelos comerciais de sensores capacitivos para determinação do teor de umidade no solo, tendo como vantagens o baixo custo e fácil utilização, sendo utilizados para aplicações em pequenas hortas e plantas para a automatização.

Tendo como base referências em relação ao custo dos sensores, os sensores capacitivos se mostram mais atingíveis os consumidores, considerando a implementação da automação de pequenos cultivos e plantas residenciais. O presente projeto visa utilizar o sensor de umidade de baixo custo, implementando em um sistema automatizado, procurando manter ou melhorar a produtividade do cultivo e reduzir os gastos hídricos.

OBJETIVOS

Este trabalho apresenta como objetivo geral reduzir problemas relacionados à irrigação e agricultura, buscando o controle e a economia de ambas as partes, aumentando a produção e diminuindo a quantidade de água utilizada e, ao mesmo tempo, minimizar a intervenção manual nas operações de irrigação, tornando uma opção eficaz para a irrigação inteligente.

       Objetivo específico

Por meio de utilização de um microcontrolador e um sensor de umidade pretende-se:

• Automatização de pequenos cultivos
• Diminuir gastos de água
• Controlar a irrigação de acordo com a necessidade da planta
• Controle e monitoramento remoto por meio de uma web server local
• Coleta de dados sobre a umidade e volume de água do cultivo

MATERIAIS E MÉTODOS

O projeto a ser desenvolvido é um sistema de irrigação automatizada, utilizando o microcontrolador esp32, na qual possui uma placa wireless, para realizar uma interface de monitoramento remoto em rede local. Para isso é necessário a utilização de sensores de monitoração do solo, uma bomba d’água e um atuador para acionamento da bomba.  

Esp32

O Esp32 faz parte de uma família de microcontroladores feitos a partir de um único chip de 2,4 GHz de baixo custo e baixo consumo de energia com conexões Wi-Fi e Bluetooth já integradas, o que facilita a implementação de um servidor local para a interface do programa.

Possui um total de 39 pinos que podem ser usados tanto para input quanto output, dentre eles, 10 pinos podem ser usados como capacitive touch pins, capazes de serem acionados apenas por um toque. Este microcontrolador é responsável por receber e enviar dados para rede local e por meio da programação a ser desenvolvida, será capaz de acionar os irrigadores. A programação será realizada na plataforma Arduino IDE utilizando a linguagem C para os sensores e atuadores e HTML para o servidor web.

Sensor de umidade

Os sensores de umidade do solo, conhecidos também como higrômetros, tem como função determinar a umidade do solo. Basicamente há dois modelos de sensores sendo eles os resistivos e capacitivos. Os sensores resistivos obtêm o teor de umidade do solo com a corrente resultante em seus terminais. Já o capacitivo apresenta uma vida útil maior em comparação aos resistivos devido a ter maior resistência a corrosão, medem a variância da capacitância que é traduzida em umidade relativa. A escolha do sensor também se difere ao uso para diferentes tipos de cultivos, pois determinados cultivos possuem as raízes mais profundas por isso precisam de sensores de maior alcance ao sistema radicular.

No presente projeto será utilizado um sensor de umidade capacitivo utilizando comunicação com o esp32 que mandará as informações para a web server local, onde será definido o valor do intervalo do teor de umidade do solo para o plantio em questão. O usuário terá o feedback da umidade do solo por meio do sensor, o qual poderá ser definido e modificado na web server, escolhendo a porcentagem em que o sistema de irrigação deverá ligar e desligar.

Atuador e bomba d’água

Para sistemas de irrigação, as bombas a serem utilizadas precisarão de tipos de atuadores diferentes para que consigam alimentá-la. Para o projeto em questão será utilizado uma bomba d’água 12V, com isso será desenvolvido um circuito de acionamento com um optoacoplador e relé. O modulo optoacoplador será desenvolvido utilizando o software Proteus que acionará a bomba de acordo com os valores de umidade especificadas pelo usuário na web server.

RESULTADOS ESPERADOS

Como resultado deste trabalho espera-se um protótipo que automatize um sistema de irrigação para pequenos cultivos a pequenas plantas, por meio do uso do ESP32 e monitoramento via web conectado à rede local, proporcionando uma redução nos gastos hídricos e aumento da produtividade pela manutenção do teor de umidade do solo designado a planta em questão.

Para disseminação dos resultados obtidos neste projeto, os dados serão apresentados para uma banca avaliadora para então determinar futuros processos a serem implementados e então decidir por uma possível publicação.

[ID:41] Autor:Lucas Gabriel Fernandes - Criado em: 2021-05-04 18:01:19 - [ Compartilhar ]

Em São Paulo, estado em que pode se encontrar uma grande quantidade de veículos elétricos em uso, a quantidade de eletropostos ainda é baixa. Em maioria, os usuários de elétricos fazem a recarga da bateria em suas próprias casas, onde precisam instalar carregadores. A imagem trás alguns dos carregadores para carros elétricos do estado. 

Fonte: https://g1.globo.com/carros/carros-eletricos-e-hibridos/noticia/2019/08/13/o-quanto-roda-onde-recarregar-custo-como-e-o-dia-dia-com-carros-eletricos.ghtml

[ID:39] Autor:Julia Maria Massareli Costa - Criado em: 2021-05-04 16:14:14 - [ Compartilhar ]

   A principal diferença na tecnologia empregada entre veículos elétricos (VEs) e veículos convencionais (VMCIs) está na configuração do powertrain, que é o conjunto de componentes que trabalham na conversão de potência do motor em movimento. Enquanto um VMCI, que utiliza um motor de combustão interna, consome grandes quantidades de combustível e gera emissões de escapamento, os veículos elétricos podem ser parcial ou totalmente abastecidos com eletricidade (AMSTERDAM ROUNDTABLES FOUNDATION, 2014).
  O sistema integrado de VEs envolve tecnologias das áreas de engenharia elétrica, mecânica e química (CHAU et al., 2017), e se divide nas subáreas de sistema de energia, sistema de propulsão e sistema auxiliar. Conforme Chau et al. (2017), o sistema de propulsão tem sido desenvolvido com o objetivo de melhorar a eficiência dos motores, a densidade de potência (potência por unidade de volume) e a densidade de torque (unidade de torque por volume), e a sua controlabilidade.
  Para veículos híbridos comuns (VEHs) e híbridos plug-in (VEHPs), Chau et al. (2017) indica que se utilizam os motores ISG (Integrated starter generator) e EVT (Electric variable transmissor), enquanto que para veículos totalmente elétricos (VEBs), os motores utilizados se enquadram nas categorias de motores DC série, DC shunt, DC de excitação independente e DC de ímã permanente, motores de indução gaiola-de-esquilo, motores síncronos PM, PM BLDC e de relutância variável.
  Conforme o estudo de Lorf et al. (2013), o powertrain pode operar nos modos de tração, frenagem, recuperação e coasting. No modo de tração, o fornecedor energético aplica uma força de propulsão às rodas, e no modo coating, a fonte de energia é desengatada e a resistência do veículo é igualada à diminuição de energia cinética. Na frenagem, os freios mecânicos dissipam energia cinética da desaceleração como calor, e na recuperação, a energia cinética da desaceleração é parcialmente recuperada e transferida para o sistema de armazenamento energético (LORF et al, 2013).
  De acordo com as características do powertrain do veículo, a bateria utilizada também varia e exerce influência considerável na utilização do veículo. Para veículos convencionais, as baterias de chumbo ácido fornecem a energia para combustão interna do motor e para o sistema elétrico do veículo (CARNEIRO et al., 2017). Quando se trata de veículos elétricos, no entanto, a bateria utilizada depende de características específicas.
  Segundo Lowe et al. (2010), para VEHs, a bateria atua principalmente na armazenagem de energia proveniente da frenagem regenerativa, assim, precisa armazenar menores quantidades de energia. Para VEHPs, a bateria necessita de maior capacidade energética e potência, enquanto para VEBs, em que o motor é carregado somente pela bateria, torna-se necessário ter grande capacidade energética, ciclos de carga/descarga completos e tamanho maior (LOWE et al., 2010). As baterias de íon-lítio, por conta de sua alta densidade energética (INTERNATIONAL RENEWABLE ENERGY AGENCY, 2017), são as mais utilizadas em veículos elétricos.
  Quanto ao sistema auxiliar dos veículos, Chau et al. (2017) indica que os desenvolvimentos tecnológicos são voltados às áreas de auxílio ao fornecimento energético, direção hidráulica e controle de temperatura, com o objetivo de reduzir o consumo energético dos eletrônicos e melhorar a capacidade do veículo de fazer manobras.
  Por conta das características de sua estrutura e powertrain, veículos que utilizam energia elétrica apresentam como maior vantagem a possibilidade de redução do emprego de combustíveis fósseis e a diminuição na emissão de gases de efeito estufa (GEE ou CO2eq) durante sua fase de uso. A produção e tratamento de fim de vida dos veículos, no entanto, também gera impactos ambientais. Assim como na fase de uso dos veículos, a fonte de energia elétrica utilizada na produção do powertrain e da bateria é o fator com maior potencial de mitigação das emissões de GEE (HELMERS; DIETZ; WEISS, 2020).
  Conforme o estudo de Transport & Environment (2020), mesmo em locais onde a eletricidade tem maior pegada de carbono, VEBs podem ser mais limpos que convencionais. Mesmo veículos elétricos híbridos, como os VEHs e os VEHPs, que apresentam uma conjunção de motor elétrico e motor a combustão interna, podem apresentar significante redução na emissão de CO2eq (INTERNATIONAL ENERGY AGENCY, 2019).
  Em vista da perspectiva ambiental positiva oferecida por esse tipo de tecnologia, as vendas globais de VEs crescem de forma significativa. Em 2019, VEBs e VEHPs foram 2,6% do total de vendas, e o estoque mundial de elétricos chegou a 7,2 milhões de veículos (INTERNATIONAL ENERGY AGENCY, 2020).
  No Brasil, entretanto, os veículos elétricos representam uma pequena parcela da frota total, que é composta, principalmente, por veículos flex-fuel e veículos a gasolina (ASSOCIAÇÃO BRASILEIRA DA INDÚSTRIA DE AUTOPEÇAS; SINDICATO NACIONAL DA INDÚSTRIA DE COMPONENTES PARA VEÍCULOS AUTOMOTORES, 2020). Apesar da pouca expressividade da tecnologia na frota, a difusão de elétricos avança anualmente. De acordo com estimativas da Associação Brasileira Da Indústria De Autopeças e do Sindicato Nacional Da Indústria De Componentes Para Veículos Automotores (2020), veículos híbridos e elétricos representavam 0,031% da frota total do país em 2018, e passaram a ser 0,1% em 2019. Quanto ao número de licenciados, em 2020, veículos leves híbridos e elétricos representaram 1% do licenciamento anual, contra apenas 0,4% de participação em 2019 (ASSOCIAÇÃO NACIONAL DOS FABRICANTES DE VEÍCULOS AUTOMOTORES, 2021).
  Segundo o estudo da Empresa de Pesquisa Energética (2020), o setor de transportes brasileiro é responsável pelo consumo de 32,7% da energia produzida no país e por 45,4% das emissões totais associadas à matriz energética. A energia utilizada nesse setor é proveniente de fontes como óleo diesel, gasolina, etanol, etc., e para veículos leves, 55% da energia para abastecimento vem da gasolina tipo A, e 45% é proveniente do etanol (EMPRESA DE PESQUISA ENERGÉTICA, 2020).
  Assim, a inserção de veículos que geram menor consumo energético e menos impacto ambiental pode ser particularmente benéfica para o país. A matriz elétrica brasileira, composta principalmente por fontes de energia renováveis (EMPRESA DE PESQUISA ENERGÉTICA, 2020), permite que a energia elétrica utilizada por VEs tenha menor pegada de carbono e que o veículo tenha menor impacto durante sua fase de uso.
  Dessa maneira, o estudo da tecnologia empregada nos sistemas auxiliar, de propulsão e de energia para VEs é importante para que se possa trazer a tecnologia às fábricas brasileiras e aumentar a adesão do uso de elétricos pela população. Para tal, é preciso entender como ocorrerá o aumento na demanda de energia elétrica e qual o impacto ambiental causado pelas emissões durante as fases de produção, uso e descarte dos veículos.

  Ademais, é preciso entender como a inserção de elétricos pode influenciar o mercado veicular brasileiro e como é possível adequar a tecnologia à matriz energética do país e otimizar sua eficiência, de maneira a diminuir os impactos ambientais causados pela frota.

REFERÊNCIAS BIBLIOGRÁFICAS

AMSTERDAM ROUNDTABLES FOUNDATION. EVolution: electric vehicles in Europe gearing up for a new phase? Amsterdam Roundtable Foundation, McKinsey & Company The Netherlands. 2014. 60 p. Disponível em: https://www.mckinsey.com/~/media/McKinsey/Locations/Europe%20and%20Middle%20East/Netherlands/Our%20Insights/Electric%20vehicles%20in%20Europe%20Gearing%20up%20for%20a%20new%20phase/Electric%20vehicles%20in%20Europe%20Gearing%20up%20for%20a%20new%20phase.ashx. Acesso em: 16 jan. 2021.
ASSOCIAÇÃO NACIONAL DOS FABRICANTES DE VEÍCULOS AUTOMOTORES. Carta da ANFAVEA 416. São Paulo: ANFAVEA, 2021. Disponível em: http://www.anfavea.com.br/cartas/carta416.pdf. Acesso em: 18 jan. 2021.
ASSOCIAÇÃO BRASILEIRA DA INDÚSTRIA DE AUTOPEÇAS; SINDICATO NACIONAL DA INDÚSTRIA DE COMPONENTES PARA VEÍCULOS AUTOMOTORES. Relatório da frota circulante. Brasil: ABIPEÇAS; SINDIPEÇAS, 2020. Disponível em: https://www.sindipecas.org.br/sindinews/Economia/2020/RelatorioFrotaCirculante_Abril_2020.pdf. Acesso em: 18 jan. 2021.
CARNEIRO, R. L.; et al. Aspectos essenciais das baterias chumbo-ácido e princípios físicos-químicos e termodinâmicos do seu funcionamento. Revista Virtual de Química: Bauru, v. 9, n. 3, p. 889-911, jun. 2017. Disponível em: http://static.sites.sbq.org.br/rvq.sbq.org.br/pdf/v9n3a06.pdf. Acesso em: 20 jan. 2021.
CHAU, K. T.; JIANG, C.; HAN, W.; LEE, C. H. T. State of the art electromagnetics research in electric and hybrid vehicles. Progress in electromagnetics research, [s.l.], v. 159, p. 139-157, 2017. Disponível em: http://www.jpier.org/PIER/pier159/10.17090407.pdf. Acesso em: 19 jan. 2021.
EMPRESA DE PESQUISA ENERGÉTICA. Balanço energético nacional 2020. Rio de Janeiro: EPE, 2020. Disponível em: https://www.epe.gov.br/sites-pt/publicacoes-dados-abertos/publicacoes/PublicacoesArquivos/publicacao-479/topico-521/Relato%CC%81rio%20Si%CC%81ntese%20BEN%202020-ab%202019_Final.pdf. Acesso em: 15 jan. 2021.
HELMERS, E.; DIETZ, J.; WEISS, M. Sensitivity analysis in the life cycle assessment of electric vs. combustion engine cars under approximate real-world conditions. Sustainability, [S.l.], v. 12, n. 1241, p. 1-31, 2020. Disponível em: https://www.mdpi.com/2071-1050/12/3/1241. Acesso em: 05 jul. 2020.
INTERNATIONAL ENERGY AGENCY. Global EV outlook. França: IEA, 2019. Disponível em: https://www.iea.org/reports/global-ev-outlook-2019. Acesso em: 18 jan. 2021.
INTERNATIONAL ENERGY AGENCY. Global EV outlook. França: IEA, 2020. Disponível em: https://www.iea.org/reports/global-ev-outlook-2020. Acesso em: 18 jan. 2021.
INTERNATIONAL RENEWABLE ENERGY AGENCY. Electricity storage and renewables: costs and markets to 2030. Abu Dhabi: IRENA, 2017. Disponível em:http://www.irena.org/publications/2017/Oct/Electricity-storage-and-renewables-costs-and-markets. Acesso em: 18 jan. 2021.
LORF, C.; et al. Comparative analysis of the energy consumption and CO2 emissions of 40 electric, plug-in hybrid electric, hybrid electric and internal combustion engine vehicles. Elsevier, Nova York, v. 23, p. 12-19, ago. 2013. Disponível em: http://www.academia.edu/28242562/Comparative_analysis_of_the_energy_consumption_and_CO2_emissions_of_40_electric_plug-in_hybrid_electric_hybrid_electric_and_internal_combustion_engine_vehicles. Acesso em: 15 jan. 2021.
LOWE, M.; et al. Lithium-ion batteries for electric vehicles: the U.S. value chain. Durham: Duke University Global Value Chains Center. 2010. 76 p. Disponível em: https://www.researchgate.net/publication/294580055_Lithium-ion_Batteries_for_Electric_Vehicles_the_US_Value_Chain. Acesso em: 19 jan. 2021.
MINISTÉRIO DO MEIO AMBIENTE. Inventário nacional de emissões atmosféricas por veículos automotores rodoviários 2013: ano-base 2012. Brasil: MMA, 2013, 115p. Disponível em: https://iema-site-staging.s3.amazonaws.com/2014-05-27inventario2013.pdf. Acesso em: 19 jan. 2021.

Fonte: Projeto de TCC de Julia Massareli

[ID:38] Autor:Julia Maria Massareli Costa - Criado em: 2021-05-04 15:54:42 - [ Compartilhar ]

O presente trabalho tem por objetivo apresentar o desenvolvimento e implantação de um sistema supervisório para monitoramento, análise e controle de um processo automático de injeção, o qual contara com uma simulação contendo seus principais atuadores, todo o processo será montado em cima do software NodeRED e o modulo ESP32, a comunicação e programação dos componentes será realizada através do uso da linguagem C/C++ e o protocolo MQTT. A finalidade do trabalho e acrescentar funções ao sistema padrão de supervisórios, o qual trabalhar com Iot (internet of things) nos possibilita abranger essa nova área chamada Internet, visando o melhoramento no desempenho e o baixo custo

Sistemas Supervisórios

Na história, nos meados da década 70/80, o avanço da eletrônica ficou cada vez mais significante, surgindo os microprocessadores, assim o computador se converteu em uma peça chave em diversos setores industriais, assim surgindo os sistemas supervisórios, teoricamente um sistema supervisório destina-se a capturar e armazenar em um banco de dados informações sobre o processo de produção, vindo de sensores.

Esp 32

O nome ESP32 se refere a um chip com função de microcontrolador produzido pela Espressif para trabalhar com dispositivos móveis e aplicações de Internet das Coisas. O ESP32 é capaz de funcionar em ambientes com temperatura na faixa de - 40°C até 125°C. O módulo contém Wi-Fi e Bluetooth integrados, podendo funcionar como um sistema standalone ou como escravo de outro dispositivo. Conta com um processador de 32 bits (Espressif, 2019).

Segundo Ibrahim (2017) o ESP32 apresenta um poderoso design de núcleo único ou núcleo duplo de 32 bits (com dois núcleos de processador físico) que pode operar em frequências diferentes, conforme mostrado na Figura 3. Possui capacidade de armazenamento exponencialmente maior até 240 MHz. Não apenas duplica a quantidade de memória flash em comparação com o modelo ATmega 2560 em comparação com o microcontrolador Arduino tradicional
A placa tem 18 entradas analógicas para conversão digital e oferece resolução de 12 bits em uma escala de 0 a 3,3 V. Essas entradas são usadas para coletar os dados do sensor fornecidos em formato analógico e convertê-los em uma escala digital. De 0 a 4095 (12 bits) a 32, você pode operá-lo posteriormente no software (ESPRESSIF, 2018).
As principais caraterísticas técnicas do microcontrolador ESP32 são:
•    CPU: Xtensa® Dual-Core 32-bit LX6;
•    ROM: 448 KBytes;
•    RAM: 520 Kbytes;
•    Portas GPIO: 11;
•    Wireless padrão 802.11 b/g/n;
•    Tensão de operação: 4,5 ~ 9V.

Node-RED

O software completamento open source, ou seja, possui códigos abertos. O que simplifica a elaboração de programas, abrangendo a área de internet das coisas, possui uma programação de blocos, cujos contém o código, a mecânica de ligar os blocos, chamados de nós, do inglês nodes. A junção dos blocos para realizar uma atividade, formam um fluxo, cujo termo usado em inglês e flow.

Protocolo MQTT

O MQTT foi criado com a ideia de coletar dados de vários dispositivos e enviá-los a um banco de dados. Seu protocolo extremamente leve o torna ideal para uso como monitor por meio de monitoramento remoto, especialmente para conexões máquina a máquina. A Figura 1 resume a estrutura básica do protocolo MQTT. Os processos tendem a ser cada vez mais eficientes, autônomos, confiáveis e personalizáveis.
A implantação de uma rede industrial com MQTT vem carregada com uma série de benefícios, como maior eficiência na distribuição de informações, o consumo da banda de rede e reduzida drasticamente, extremamente leve e de fácil manipulação e a segurança baseada em permissão.

Objetivo

Realizar a simulação e demonstração de um ambiente industrial, destacando uma máquina industrial, no qual será usado um motor, um inversor de frequência, encoder e sensores. Já com o software Node-RED será feito um modelo supervisório mostrando a interação em tempo real, para fins de um entendimento completo do seu funcionamento e controle.

 Objetivos Específicos 

•    Utilizar o conceito Iot para tratamento e transmissão dos dados coletados através do microcontrolador ESP32
•    Pesquisa sobre o protocolo MQTT para a comunicação
•    Pesquisa e estudo sobre a ferramenta de programação NodeRED e linguagem C/C++
•    Implementar o sistema de servidor local e dashboard (supervisório) que possibilitara o usuário observar o processo em tempo real
•    Realizar testes nos sensores que serão utilizados
•    Realizar testes na comunicação para avaliar os dados medidos
•    Realizar a montagem física do trabalho

Referencias

ESPRESSIF. ESP32-WROOM32 Datasheet. 2021. Disponível em: https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32_datasheet_en.pdf. Acesso em: 05 maio. 2021

[ID:37] Autor:Jeremy Gian Carlo Janko Vilca - Criado em: 2021-05-04 14:56:51 - [ Compartilhar ]

Atualmente as pessoas estão buscando cada vez mais comodidade e praticidade, fazendo com que a automação residencial se torne uma opção capaz de trazer mordomia e facilidade para essas pessoas. Inicialmente a automação residencial começou como um produto de difícil acesso e alto custo, porém, essa realidade está mudando. Com o surgimento de novas tecnologias, a aplicação da automação tem se tornado cada vez mais acessível, como consequência, barateando e aumentando sua viabilidade.

Esse trabalho propõe elaborar um sistema de automação residencial eficiente, que pode ser acessado de qualquer lugar que você esteja.

Para realizar esse projeto, é preciso estabelecer objetivos específicos:

• Criar uma instância EC2 na Amazon Web Services (AWS);
• Instalar Apache, MySQL e PHP na instância;
• Criar um RDS na AWS e configurar ele através do MySQL;
• Instalar o Node-RED na instância EC2;
• Utilizar o protocolo MQTT no Node-RED e no microcontrolador (Esp32);
• Construir uma interface dashboard através do Node-RED para que o usuário possa realizar o controle e visualizar os dados pela mesma;
• Integrar o banco de dados RDS no Node-RED;
• Desenvolver o circuito e integrar o Esp32;
• Aplicar o sistema na residência.

Esse trabalho é um complemento ao TCC de Pedro Eduardo Suga Machado sobre "Automação residencial visando um melhor gerenciamento energético".

Diagrama esquemático do controle do relay:

                                                                                      →  +  → → 

Diagrama esquemático da coleta de dados do sensor:

                                                                             ←  ++  ←←

Dashboard desenvolvida no Node-RED:

[ID:36] Autor:Pedro Eduardo Suga Machado - Criado em: 2021-04-27 21:21:39 - [ Compartilhar ]

A lâmpada UV-C foi descoberta em meados de 1800 como uma forte fonte descontaminante, sendo confirmado como esterelizadora na década de 1960. Com essa confirmação também teve a confirmação que para isso, a lâmpada teria que atender certos critérios como velocidade de acordo com a potência da lâmpada. Porém essa lâmpada também é nociva para humanos se houver grande exposição, por isso procura-se há tempos um meio de utilizar essa função de forma segura. 

Esse projeto tem como objetivo montar um robô que percorra uma superfície de forma autônoma, com a lâmpada acoplada, assim como um circuito eletrônico que controle as ações desse robô. O acionamento e mudança de ações desse projeto será através de um controle remoto via wifi, com isso utilizando um ESP32 para tal ação.  

A lâmpada utilizada será uma da OSRAM de 4W, como mostra a figura a seguir. Essa lâmpada tem dimensões pequenas (15 centímetros), porém essa escolha surgiu pois essa é de um tamanho que possibilita o acoplamento sem danificar o robô escolhido e que se encaixa em dimensões com o do robô.

O robô escolhido foi o EXPLORERDS, que é um robô esteira, e que possui garras controláveis, além de possuir espaço para expansão de autonomia além da do fabricante, sem necessitar de designers mirabolantes ou perda da autonomia.

O trabalho contará com uma página online, onde terá o controle do acionamento e interrupção do funcionamento do robô, além de poder ver os dados do sensor ultrassônico. 

[ID:35] Autor:Suzanne Kellen dos Santos - Criado em: 2021-04-27 20:27:02 - [ Compartilhar ]

FUNDAMENTAÇÃO TEÓRICA

As indústrias constantemente buscam aprimorar a qualidade e flexibilidade dos processos. Para isso são utilizados sensores que permitem o monitoramento dos processos de forma precisa e automática. Existem no mercado sensores de aplicações diversas, que podem ser utilizados para determinar valores essenciais para a realização de determinadas tarefas. Para medições em deslocamentos lineares, o sensor mais aplicado é o LVDT (DIAS, 2015). Os LVDT 's (Linear variable differential transformers) são uma categoria de sensores de deslocamento linear que permite uma medição muito precisa. Chegando até 0,001 mm de precisão (KEYENCE, 2021), podendo ser acompanhada por um sistema supervisório. O sensor possui três bobinas dispostas em série ao longo de um tubo. De forma que um núcleo metálico ferromagnético possa se deslocar no interior das bobinas. A bobina central é chamada de primária e as outras duas bobinas laterais são chamadas de secundárias. O núcleo móvel é unido a uma haste não metálica usada para realizar a medição. A figura 2.1 mostra um esquematico do funcionamento do sensor.

                           Figura 2.1 Esquemático sensor LVDT

              Fonte: Adaptado de Greif, Sassa e Fukuoka (2006).

Segundo Félix et al. (2010) uma corrente alternada de alta frequência (de 1 a 10 KHz) é aplicada à bobina primária, gerando a corrente a ser induzida em cada bobina secundária. Conforme o núcleo se move, a indução nas bobinas secundárias muda, gerando uma variação na tensão de saída. Sendo assim, é necessário que o sinal seja condicionado por meio de um circuito de instrumentação que irá retificar, filtrar e amplificar a saída do transformador. O sensor LVDT é amplamente utilizado para medir grandezas diversas baseado na distância de deslocamento. Por exemplo, ao aplicar uma força a uma mola de constante conhecida, pode-se medir a deformação da mola por meio de um LVDT e então determinar a força aplicada. Outra aplicação possível é a medição de pressão diferencial. Acoplando um LVDT a um tubo de Venturi, a diferença de pressão ao longo do tubo irá atuar o LVDT por meio de membranas. As aplicações acima utilizam o LVDT de forma indireta, pois ele é aplicado em conjunto com um sistema para determinar outros parâmetros que originalmente ele não mede. Uma aplicação que o utiliza diretamente é a de determinar deflexão em vigas ou até em ensaios mecânicos de ruptura (SAVARIS; PINTO, 2017). Também é muito aplicado para controle de qualidade de superfícies de peças usinadas (KEYENCE, 2021). No mercado existem diversos fabricantes que produzem o sensor como a Keyence (2021), a MTS sensors (2021) e a RDP group (2021). Os seus custos são extremamente elevados, sendo os mais baratos próximos a R$ 400,00. O alto custo torna a sua aplicação em laboratórios acadêmicos praticamente inviável. Dessa maneira, esse trabalho visa à construção de um LVDT de pequeno porte com baixo custo e sua aplicação em um sistema de controle de posição de um atuador linear.

Objetivos

O presente trabalho tem como objetivo a construção e calibração de um sensor LVDT de baixo custo para aplicações de controle de posição de um atuador linear, bem como desenvolver um sistema de monitoramento Web para que a leitura dos valores do sensor seja feita de forma remota.

Materiais e métodos

• Esp32;
• Desenvolvimento de um sensor LVDT;
• Montagem dos circuitos de alimentação e instrumentação
• Desenvolvimento da programação do banco de dados;
• Coleta de dados dos sensores para o banco de dados.

Utilizando o Esp32 é feito uma comunicação via internet para que envie um sinal para o atuador e receba do sensor qual posição o atuador está. Esse programa é feito apartir do Node Red com MQTT em dominio público para que seja monitorado de qualquer local com acesso a internet.

REFERÊNCIAS BIBLIOGRÁFICAS

DIAS, Rogerio Paulo Ferraz. Transdutor Diferencial de Variação LinearCondicionamento de Sinal e Desmodulação Síncrona. 2015. Dissertação(Mestrado em Engenharia Eletrotécnica)- Faculdade de Engenharia de Lisboa, Instituto Superior de Engenharia de Lisboa, Lisboa, 2015.

FELIX, M.; LIZARRAGA, A.; ISLAS, A.; GONZALEZ, A.. Analysis of a ferrofluid core LVDT displacement sensor. Iecon 2010 - 36Th Annual Conference On Ieee Industrial Electronics Society, [S.L.], jan. 2010. IEEE. http://dx.doi.org/10.1109/iecon.2010.5675411.

GREIF, Vladimir; SASSA, Kyoji; FUKUOKA, Hiroshi. Failure mechanism in an extremely slow rock slide at Bitchu-Matsuyama castle site (Japan). Landslides, [S.L.], v. 3, n. 1, p. 22-38, 10 fev. 2006. Springer Science and Business Media LLC. http://dx.doi.org/10.1007/s10346-005-0013-0.Keyence Brasil. Disponível em: . Acesso em: 21 de maio de 2021.

MTS Sensors. Disponível em: < https://www.mtssensors.com/Products/IndustrialPositionSensors?creative=249847231389&keyword=lvdt%20sensor&matchtype=p&network= g&device=c&gclid=CjwKCAjwtJ2FBhAuEiwAIKu19iM8hXwVQAxth21OzNXTBv5Puy qnBAhwwBe3NId7_5L7qyh2HPPkzBoCzfsQAvD_BwE>. Acesso em: 21 de maio de 2021.

RDP Group. Disponível em: . Acesso em: 21 de maio de 2021.

SAVARIS, G.; PINTO, R. C. A.. Influence of coarse aggregate on shear resistance of selfconsolidating concrete beams. Revista Ibracon de Estruturas e Materiais, [S.L.], v. 10, n. 1, p. 30-40, fev. 2017. FapUNIFESP (SciELO). http://dx.doi.org/10.1590/s1983-41952017000100003

[ID:34] Autor:Guilherme Lanzi Ernandes - Criado em: 2021-04-27 20:10:15 - [ Compartilhar ]

O uso de motores pode ser evidenciado em diversos processos, e na grande maioria é necessário o controle de velocidade e o sentido de rotação do eixo, para fazer esse controle será utilizado circuitos inversores de frequência. Os inversores de frequência são equipamentos conversores de potência DC em potência CA, onde a saída é adequada às características desejada, tensão, corrente e frequência (AHMED, 2000).
A conversão de energia CC para CA é comumente utilizada em diversos equipamentos e sistemas eletrônicos. Essa conversão é basicamente feita utilizando interruptores eletrônicos. A característica fundamental desses circuitos, está no funcionamento dos interruptores atuando na condução e bloqueio.
Os circuitos inversores são divididos em dois grupos: inversores de fonte de tensão (Voltage source inverters – VSI) e inversores de fonte ideal de corrente (current source onverters – CSI). Os inversores (VSI) utilizam uma fonte de tensão constante e independente da corrente consumida. Da mesma forma, os inversores (CSI) utilizam uma fonte de corrente constante e independente da variação de tensão de entrada. Os inversores de tensão possuem maior aplicação e são baseados na modulação por largura de pulso (PWM).
Segundo Ahmed (2010) os três tipos de modulação por largura de pulso (PWM) mais utilizado são: modulação por largura de pulso simples, modulação por largura de pulso múltipla e modulação por largura de pulso senoidal.

Há diferentes circuitos e topologias que se aplicam aos três tipos de inversores de tensão mais utilizados. Esses circuitos serão intensivamente estudados para constituir uma aplicação capaz de ajudar a compreensão do funcionamento dos circuitos inversores.

Objetivo Geral
Construção de um sistema didático conversor de tensão do tipo inversor baseado em três tios fundamentais da literatura com objetivo de demonstrar didaticamente o funcionamento dos circuitos conversores CC/CA.

O projeto proposto possui a relevância de atuar auxiliando o ensino das disciplinas do curso de Engenharia de Controle e Automação e nos laboratórios de eletrônica e microcontroladores, bem como, no fomento de novas linhas de pesquisa.
Finalmente, ao término deste projeto espera ter-se construído um sistema composto por um circuito monofásico inversor de frequência didático para auxiliar no ensino teórico e prático de disciplinas do curso de engenharia.

[ID:33] Autor:Daniel Gustavo de Souza Rodrigues - Criado em: 2021-04-27 20:06:27 - [ Compartilhar ]

Redirecionamento DDNS

Crie uma conta no Duckdns para traduzir a URL IP em formato amigável com nomes.

O Duck DNS é um serviço que permite traduzir o endereço IP dinâmico de seu servidor na nuvem (AWS) ou local (Raspberry, computador ou outro equipamento) que está utilizando um endereço de URL fornecido pela operaadora (VIVO, Claro, etc). para um nome ex: http://embarcadosifsp.duckdns.org. Este serviço está alojado na plataforma de cloud de Amazon e o código do serviço está disponível sob a licença GNU GPLv3. Visite o site http://www.duckdns.org , conecte-se utilizando uma rede social ou github. Criado a conta, copie o Token (YOUR_TOKEN). Adicione um domínio (domains YOUR_DOMAIN) que será apontado. Os domínios apontaram para o mesmo ip se os servidores estiverem na mesma rede e ip público. Cabe instalar um script para conectar, e utilizar portas diferentes em cada domínio configurando o modem/roteador para o ip correto interno.

Para que o Duck DNS atualize automaticamente, é preciso que seu servidor rode um pequeno script periodicamente e informe o servidor DuckDns. Como estamos utilizando linux para nosso os desenvolvimentos de projetos, vamos utilizar o serviço CRON  que automaticamente rodará o script .sh em intervalos de tempos pré definidos.

Crie uma pasta para instalar o script:

mkdir /home/pi/duckdns

cd /home/pi/duckdns

nano duck.sh

Dentro do arquivo insira o seguinte texto:

echo url="https://www.duckdns.org/update?domains=[YOUR_DOMAIN]&token=[YOUR_TOKEN]&ip=" | curl -k -o ~/duckdns/duck.log -K -

Salve o arquivo e dê permissão de execução

chmod 700 duck.sh
Agora acesso o seriço Crontab para configurar a execução em intervalos de tempo.
crontab -e

Insira este texto para executar o script a cada 5 minutos. Pode-se aumentar o intervalo.

*/5 * * * * /home/pi/duckdns/duck.sh >/dev/null 2>&1

Confira a execução e log

./duck.sh
cat duck.log
sudo service cron start

Formatação do CRONTAB

Comandos:

crontab -l    		# Viewing the cronjobs as currently logged in user 
crontab -e    		# Edit the cronjob for currently logged in user

Exemplos de configuração CRONTAB

Todos os dias as 6 am

0 6 * * *  /home/eazylinux/script.sh

A cada 5 minutos

*/5 * * * *  /home/eazylinux/script.sh

Ajustar o horário do servidor Ubuntu

timedatectl é uma ferramenta para controle de data e horário do sistema. Pode ser usado para alterar o relógio e suas configurações. Definindo fuso horário como São Paulo:

$ sudo timedatectl set-timezone America/Sao_Paulo

Referências:

Criando uma conta DNS https://pplware.sapo.pt/informacao/duck-dns-servico-dns-dinamico-totalmente-gratuito/

Configurando Cron e duck.sh:  https://www.wundertech.net/how-to-setup-duckdns-on-a-raspberry-pi/

Crontab tips and tricks https://www.eazylinux.com/crontab-tips-and-tricks/

[ID:30] Autor:Marcos Aparecido Chaves Ferreira - Criado em: 2021-04-27 16:07:13 - [ Compartilhar ]

Utilizando scripts do repositório: https://github.com/mchavesferreira/ajaxdados podemos construir uma dashboard básica.

O script temperaturasendjson.php publica os últimos dado de um banco de dados no formato JSON.

O script buscajson.php exemplifica uma API simples em PHP que separa em uma nova hieraquia e campos desejados de uma JSON.

O script index.php exemplifica a utilização de javascript e php para geração de Ajax.

Ajax é uma forma atualizar apenas uma parte da página ou campo de pagina sem precisar de uma atualização da pagina inteira, gerando chamadas  assíncronas. Este exemplo utiliza a biblioteca JQuery, simplificando o uso de códigos. O script embutido no corpo do código html, realiza o método GET em duas URL. Uma URL é código que busca em nosso banco de dados ( temperaturasendjson.php) e a outra URL busca dados de cotação do Bitcoin em formato Json. O script separa os campos desejados e substitui no corpo do texto os campos da classe

por exemplo.

Baixe o repositório direto no linux:  git clone https://github.com/mchavesferreira/ajaxdados

Referências: 

Códigos de resposta do HTTP: https://developer.mozilla.org/en-US/docs/Web/HTTP/status

Video 1: Tutorial AJAX + JSON com Java Script puro https://www.youtube.com/watch?v=YzMTXID1U9Q

Requisições AJAX com JQUERY + JSON https://www.youtube.com/watch?v=4v0PhQs08DI&

[ID:29] Autor:Marcos Aparecido Chaves Ferreira - Criado em: 2021-04-27 15:08:12 - [ Compartilhar ]

Esta aula explicaremos o que é um banco de dados, revisão de métodos GET e POST para envio de dados utilizando o nodemcu para armazenar dados na nuvem. Para começar é preciso ter um servidor linux com serviço de web e bancos de dados com acessos a comandos padrões SQL. Utilizaremos o serviço de instância AWS, porém pode ser realizado localmente em sua rede intranet, desde que o nodemcu e o servidor web tenham acesso entre si. A seguir apresentamos a video aula gravada no TEAMS, e disponilizamos os códigos necessários para implementar no repositório Github e os comandos básicos de SQL utilizados para construir este exemplo de aplicação.

Repositório de arquivos:  https://github.com/mchavesferreira/php_app

Para instalação utilizar o comando:  git clone https://github.com/mchavesferreira/php_app

Aula síncrona TEAMS Banco de dados e requisições POST e GET

5:59 Protocolo Http, www, TCP/IP, DNS

12:05 Requisições GET e POST

15:44 Projeto NodeMcu

22:28 Introdução ao Mysql.

38:31 Repositório projeto php_app Comentários sobre arquivos

41:01 - Criando base de dados, uso de comandos SQL

56:20 Utilizando RDS com base de dados e uso do repositório php_app

1:06:30 Inserindo dados via POST e GET via php

1:09:59 Uso de um código .ino para envio de dados via GET e POST (arquivo1 e  arquivo2)

Comandos básicos Mysql

// conecta com o banco de dados via terminal localmente

 mysql -u root -p

Acesso remoto utilizando rds

mysql -u admin -h database-1.cscbnowewjwj.sa-east-1.rds.amazonaws.com -p

// mostra base de banco de dados

show databases;

// Cria base de dados

Create Database meubanco;

// seleciona base de dados

use meubanco;

// CRIA TABELA

CREATE TABLE tempLog (

timeStamp TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,

temperature int(11) NOT NULL,

humidity int(11) NOT NULL,

PRIMARY KEY (timeStamp) );

// descreve características da base de dados

describe tempLogo;

// insere uma linha de dados

INSERT INTO tempLog (temperature, humidity) VALUES ('33','56');

// Exemplo de comandos para seleção de dados todas as linhas da base de dados

SELECT * FROM tempLogo;

SELECT temperature FROM tempLogo;

SELECT * FROM tempLogo limit 1; // limita 1 linha

SELECT * FROM tempLogo limit 2,3; // limita 1 linha

SELECT * FROM tempLogo order by timeStamp ASC;

SELECT * FROM tempLogo order by timeStamp DESC;

SELECT * FROM tempLogo where temperature=23;

SELECT * FROM tempLogo WHERE DATE(timeStamp) = CURDATE();

SELECT * FROM tempLogo WHERE DATE_SUB(CURDATE(),INTERVAL 1 DAY);

//apagar linhas da tabela por seleção

DELETE from tempLogr where humidity=50;

// apagar tabela completa

DROP TABLE tempLogr;

// alterar um campo na tabela

UPDATE users SET nome = Marcos, email = mchavesferreira@gmail.com WHERE ra=CT120893;

// adicionar colunas mysql

ALTER TABLE users ADD COLUMN urljson VARCHAR(120);

ALTER TABLE blogusers ADD COLUMN  summary TEXT;

// deletar coluna da tabela

ALTER TABLE DROP COLUMN ;

//modificar coluna

ALTER TABLE blogusers MODIFY title varchar(60);

// Select com agrupamento de dados

http://www.artfulsoftware.com/infotree/qrytip.php?id=78

Referências:

ESP32/ESP8266 Insert Data into MySQL Database using PHP and Arduino IDE:  https://randomnerdtutorials.com/esp32-esp8266-mysql-database-php/

Guia Mysql: https://dev.mysql.com/doc/refman/8.0/en/creating-tables.html

Playlist Curso de Banco de daos Mysql. Curso em Vídeo https://www.youtube.com/playlist?list=PLHz_AreHm4dkBs-795Dsgvau_ekxg8g1r

[ID:28] Autor:Marcos Aparecido Chaves Ferreira - Criado em: 2021-04-27 11:29:51 - [ Compartilhar ]

Metodologia e Aplicações De Uma Bancada Didatica. 

O presente projeto tem como objetivo a aquisição de dados de um de uma bancada  didatica para o estudo de letronica de potencia lendo os sensores para acesso remoto para o acompanhamento de possiveis falhas na execução do da bancada e o  acompanhamento das varieaveis que estão lendo na bancada, facilitando o acomanhaento do da pessoa que estra utilizando o mesmo, sendo usado para a aprimoramento do conteudo didatico, tendo em vista efetuar uma melhor apresentação do IHM  para o aluno que estiver utilzando e o professor que estiver ensinando e trazer uma tecnologia mais atual e concreto para dentro da sala de aula. 

Para realizar esse projeto, é preciso estabelecer objetivos específicos:

• Criar uma instância EC2 na Amazon Web Services (AWS);
• Instalar Apache, MySQL e PHP na instância;
• Criar um RDS na AWS e configurar ele através do MySQL;
• Instalar o Node-RED na instância EC2;
• Utilizar o protocolo MQTT no Node-RED e no microcontrolador (Esp32);
• Construir uma interface dashboard através do Node-RED para que o usuário possa realizar o controle e visualizar os dados pela mesma;
• Integrar o banco de dados RDS no Node-RED;
• Desenvolver o circuito e integrar o Esp32;
• Aplicar o sistema na bancada de joelho;

O respectivo trabalho consta como um complemento do TCC do aluno Murillo Ferraz Veiga Araujo sobre "Desemvolvimento de bancada Didatica para estudo de eletrônica de potencia". 

Os dados serão coletados utilizando o ESP32 (Figura 2) e armazenados em uma database.

                                                                            FIGURA 2. ESp 32

                                                                fonte: proprio autor 

Para visualizar os dados lidos pelo sensor, foi elaborado um dashboard por meio da ferramenta Node-Red. Foi utilizado também o editor de código-fonte Visual Code para elaborar a programação, bem como uma máquina virtual, para possibilitar a comunicação.observada na figura 3 abaixo.

                                                                            FIGURA 3. node red 

                                                    fonte: proprio autor 

Na interface desenvolvida pode-se observar graficos e indicadores das variaveis para facilitar a visualização. A figura 4 representa  a dashboard elaborada. A mesma apresenta um comando de armazenamento de bancos de dados. 

                                                 FIGURA 4. dashboard

                                                                   fonte: proprio autor 

[ID:27] Autor:Murillo Ferraz Veiga Araujo - Criado em: 2021-04-27 01:11:40 - [ Compartilhar ]

A energia elétrica é a principal fonte do desenvolvimento de qualquer setor daquilo que hoje compreendemos como sociedade. Seja na indústria, na medicina, na agricultura ou até mesmo na cultura, a energia elétrica está enraizada nos avanços e nas inovações de cada setor sendo ela necessária para todo avanço socioeconômico que é refletido em melhorias na qualidade de vida de todos.

Atender e acompanhar a demanda de energia elétrica não é uma tarefa fácil, requer planejamento de longo prazo e investimentos maciços em infraestrutura para geração e transmissão. No Brasil, entre junho de 2001 a fevereiro de 2002, falhas no planejamento decorrentes de diversos fatores, implicaram no evento que ficou popularmente conhecido como “apagão”. Bardelin (2004) aponta que os responsáveis pela produção de energia elétrica não realizaram os devidos preparos para suportar o crescimento da demanda. Por outro lado, tal evento foi responsável por criar novas diretrizes e estratégias com a finalidade de impedir o “apagão” de acontecer novamente.

O Brasil dispõe de uma das maiores capacidades hídricas do mundo e, por esse motivo, concentra sua matriz energética em usinas hidroelétricas. Em contrapartida, a escassez de chuvas foge do controle do homem e interfere diretamente na capacidade de produção das mesmas. Baseado nas fragilidades da matriz energética brasileira o governo lançou por meio da Lei n° 10.438/2002 o Programa de Incentivo às Fontes Alternativas de Energia Elétrica (Proinfa) que foi uma das primeiras respostas ao “apagão” com o objetivo de disponibilizar de maneira mais rápida uma pequena parcela da demanda e regulamentar as pequenas geradoras de energia elétrica advindas de fontes renováveis.

No decorrer do tempo, a necessidade da redução de impactos ambientais provenientes da produção de energia elétrica, impulsionou o desenvolvimentos de tecnologias limpas sendo a tecnologia fotovoltaica, a que apresenta melhores soluções no atual contexto de geração distribuída. O Ministério de Minas e Energia, por meio da Portaria MME n° 538/2015 criou o Programa de Desenvolvimento da Geração Distribuída de Energia Elétrica (ProGD), no qual, buscando principalmente a utilização da fonte solar de energia, incentivar a instalação de geradores de energia elétrica cada vez mais próximos do local de consumo e amenizar os astronômicos investimentos em grandes redes de distribuição e usinas geradoras que, normalmente são instaladas a centenas de quilômetros das unidades consumidoras.

Por ser um país de dimensões continentais, o Brasil apresenta características muito diversificadas no que tange a incidência de radiação solar. De acordo com o Atlas Brasileiro de Energia Solar (2017), o mercado de geração de energia solar fotovoltaica se mostra promissor, tendo em vista, a queda crescente nos custos financeiros iniciais, incentivos governamentais e privados a financiamentos que amortizam o tempo de retorno do investimento e, principalmente, a geração de energia que atenua os picos da demanda que ocorrem, com maior frequência, no período que a geração solar fotovoltaica é maior.

Apesar da constante evolução na área, Duarte (2019) indica que a disseminação em grande escala da tecnologia de geração de energia a partir de placas fotovoltaicas encontra diversos obstáculos. Um dos entraves é a interferência de fatores intrínsecos ao movimento da terra com relação ao sol, o que implica diretamente nos índices de radiação solar. Tal interferência é responsável pelo aproveitamento de apenas um quinto da capacidade total das instalações de placas fixas.

Na busca pelo melhor aproveitamento da radiação solar que, embora não seja renovável mas sim infinita, o estudo de técnicas como sistemas de seguidores solares se apresenta como uma alternativa que segundo Cassares (2016), pode causar um ganho entre 15% e 30% quando comparado a instalações fixas. A principal particularidade da aplicação desse sistema é evitar o sombreamento da placa de modo automático por meio de sensores e atuadores que buscam manter as placas sempre normal com relação a incidência solar.

[ID:26] Autor:Renan Saher Fuzita - Criado em: 2021-04-27 01:10:58 - [ Compartilhar ]

   O objetivo geral da pesquisa é realizar o monitoramento remoto da temperatura da água de um chuveiro elétrico, mostrando em tempo real os valores lidos pelo sensor de temperatura (DS18B20) em dashboards.

   Como resultado deste trabalho espera-se obter dados da temperatura, poder analisá-los. A intenção de criar esse sistema supervisório é facilitar na posterior análise do controle PID da potência da resistência (por conseguinte, da temperatura da água) e facilitar na plotagem de gráficos no software Excel. 

[ID:25] Autor:Francisco Garcia Braghini - Criado em: 2021-04-27 01:10:15 - [ Compartilhar ]