NarrowBand – Internet das Coisas (NB-IoT)

Escrevemos em artigos anteriores sobre as redes com tecnologia Lora, Sigfox e, agora, fechamos a ideia destas redes com o NarrowBand-Internet of Things (NB-IoT), que é a “menina dos olhos” das operadoras de telefonia, que estão criando equipes internas de desenvolvimento e time de vendas para oferecer automação predial e as diversas outras funções de IoT que irão trafegar sobre a rede de celular. Neste contexto, o NB-IoT casa como uma luva, uma vez que utiliza a rede de dados 2G, 3G e 4G/LTE para transporte dos dados dos diversos sensores, barateando a infraestrutura.

 

Sistema de medição de energia solar com uso de sensores com NB-IoT
Figura 1 – Sistema de medição de energia solar com uso de sensores com NB-IoT

 

O NB-IoT é uma tecnologia de grande área de cobertura e de baixa potência (LPWA), baseada em padrões desenvolvidos para permitir uma ampla gama de novos dispositivos e serviços de IoT. O NB-IoT melhora significativamente o consumo de energia dos dispositivos do usuário, com baterias que podem durar mais de 10 anos e eficiência do espectro, especialmente na cobertura.

Novos sinais e canais da camada física são projetados para atender ao exigente requisito de cobertura estendida, além de ambientes rurais, com dispositivos sendo construídos de forma simples e barata. Espera-se que o custo inicial dos módulos NB-IoT seja comparável aos dispositivos que já utilizam o GSM/GPRS. Esta tecnologia é, no entanto, muito mais simples do que os atuais dispositivos que trabalham com as redes GSM/GPRS e seu custo deverá diminuir rapidamente à medida que a demanda aumentar.

É suportada por todos os principais fabricantes de equipamentos móveis, chipsets e módulos, e pode coexistir com redes móveis 2G, 3G e 4G, além de se beneficiar de todos os recursos de segurança e privacidade das redes móveis, como suporte a confidencialidade de identidade de usuário, autenticação de entidade, integridade de dados e identificação de equipamentos móveis. Os primeiros lançamentos comerciais da NB-IoT foram concluídos e já existe ampla implantação global desta tecnologia.

A última especificação foi a de Release 13 (LTE Advanced Pro), em junho de 2016, incluindo a eMTC (Enhanced Machine-Type Communication) e o EC-GSM-IoT (vide tabela 1).

O NB-IoT usa um subconjunto do padrão LTE, mas limita a largura de banda a uma única banda estreita de 200 kHz, com modulação OFDM para comunicação de downlink e SC-FDMA para comunicações de uplink.

 

Tabela 1 – Padrões 3GPP
Tabela 1 – Padrões 3GPP

 

O NB-IoT é projetado para três tipos de funcionamento:

  • em bandas licenciadas independentemente;
  • em bandas de 200 kHz não utilizadas anteriormente para GSM ou CDMA;
  • em estações base LTE que podem alocar um bloco de recursos para operações NB-IoT ou em suas faixas de guarda (onde as regras permitirem).

Para enviar dados para um aplicativo, duas otimizações, aqui chamado de CIoT (Celular IoT) no sistema de pacotes evoluídos (EPS) foram definidas, o User Plane CIoT (otimização de EPS) e a otimização do plano de controle do EPS, conforme figura 2. Ambas as otimizações podem ser usadas, mas não estão limitadas a dispositivos NB-IoT.

 

Rede de transmissão e recepção de dados NB-IoT
Figura 2 – Rede de transmissão e recepção de dados NB-IoT

 

Na figura 2, em vermelho está indicado o Plano de Controle CIoT, e em azul está indicada a otimização EPS (User Plane CIoT).

Na otimização do EPS, o plano de controle do CIoT, os dados do UE são transferidos do eNB (CIoT RAN) para o MME. De lá, eles podem ser transferidos por meio do serviço Gateway (SGW) ao gateway de rede de dados por pacotes (PGW) ou à capacidade de serviço Exposure Function (SCEF), que, no entanto, só é possível para pacotes de dados não IP.

A partir desses nós, eles são finalmente encaminhados para o servidor de aplicativos (CIoT Services).

Os dados são transmitidos pelos mesmos caminhos na direção inversa. Nesta solução, não há portadora de rádio de dados configurada, ou seja, os pacotes de dados são enviados na portadora de sinalização do rádio. Consequentemente, esta solução é mais apropriada para a transmissão de pacotes de dados de pouca frequência e pequenos, como os dados enviados por sensores prediais.

O SCEF é um novo nó projetado especialmente para dados de sensores. É usado para entrega de dados não-IP sobre o plano de controle e fornece uma interface abstrata para os serviços de rede (autenticação e autorização, descoberta e acesso a rede e capacidades).

Com a otimização EPS de CIoT do plano do usuário, os dados são transferidos de forma convencional, ou seja, por meio de portadoras de rádio via SGW e PGW para a aplicação do servidor. Isto cria uma certa sobrecarga na construção da conexão, no entanto, facilita uma sequência de pacotes de dados a serem enviados. Este caminho suporta tanto IP quanto entrega de dados não IP.

 

Modos de Operação

A tecnologia NB-IoT ocupa uma largura de banda de  180 kHz, que corresponde a um bloco de recursos na transmissão LTE. Com esta seleção, os modos de operação abaixo são possíveis.

  • Operação autônoma: um cenário possível é a utilização das atuais frequências do GSM, com uma largura de banda de 200 kHz e com um intervalo de guarda de 10 kHz permanecendo em ambos os lados do espectro.
  • Operação com banda de guarda: utilizando os blocos de recursos não utilizados dentro de uma faixa de guarda da operadora LTE.
  • Operação em banda: utilizando blocos de recursos dentro de uma portadora LTE.

Esses modos são visualizados na figura 3, abaixo.

 

Modos de operação
Figura 3 – Modos de operação

 

Na operação em banda, a atribuição de recursos entre LTE e NB-IoT não é fixo. No entanto, nem todas as frequências, ou seja, blocos de recursos dentro da portadora LTE, são permitidos para serem usados para conexão celular. Eles estão restritos aos seguintes valores da tabela 2:

 

Tabela 2 – Valores de banda
Tabela 2 – Valores de banda

 

Como indicado na tabela 2, não há suporte para operação em banda utilizando LTE com largura de banda de 1,4 MHz, uma vez que existe um conflito entre recursos usados pelo sistema LTE, como os sinais do celular em referência específica (CRS) ou o canal de controle de downlink no início de cada subquadro, que deve ser levado em conta quando os recursos são alocados para NB-IoT. Isto é também refletido na tabela 1, por não usar os 6 blocos internos, pois eles são alocados para os sinais de sincronização no LTE.

Para a operação com banda de guarda, o UE apenas executa uma sincronização, uma vez que se utiliza a banda na faixa de guarda.

Para lidar com diferentes condições de rádio, pode haver até 3 níveis de melhoria (CE), de nível CE 0 a nível CE 2. O nível CE 0 corresponde ao nível normal de cobertura, o nível CE 2 é utilizado para o pior caso, ou seja, onde a cobertura pode ser assumida como muito pobre. Uma lista de limiares de potência para os sinais de referência recebidos é transmitida na célula para cada nível de CE. O principal impacto dos diferentes níveis de CE é que as mensagens devem ser repetidas várias vezes para evitar perdas.

Para o Release 13, o FDD half-duplex tipo B é escolhido como o modo duplex. Isso significa que UL (uplink) e DL (downlink) são separados em frequência e o UE recebe ou transmite não simultaneamente. Além disso, entre cada comutador de UL para DL ou vice-versa, há pelo menos um subquadro de guarda (SF) no meio, onde o UE tem tempo para alternar sua cadeia de transmissor e receptor.

 

Alguns Exemplos de Aplicações

 

  • Medição Inteligente

O NB‑IoT é adequado para a monitorização de medidores de gás e água por meio de transmissões de dados regulares e pequenas. A cobertura de rede é uma questão fundamental nos lançamentos de medição inteligente. Os medidores têm uma tendência muito forte a aparecer em locais difíceis, como em subsolos ou em áreas rurais remotas. O NB‑IoT possui excelente cobertura e penetração para resolver esse problema.

 

  • Cidades Inteligentes

O NB‑IoT pode ajudar um governo local a controlar a iluminação das ruas, determinar quando as latas de lixo precisam ser esvaziadas, identificar lugares de estacionamento gratuitos, monitorar as condições ambientais e avaliar as condições das estradas.

 

  • Edifícios Inteligentes

Os sensores conectados ao NB‑IoT podem enviar alertas sobre problemas de manutenção de edifícios e executar tarefas automatizadas, como controle de luz e aquecimento. O NB‑IoT também pode funcionar como backup para a conexão de banda larga do edifício. Algumas soluções de segurança podem até usar redes LPWA para conectar sensores diretamente ao sistema de monitoramento, já que essa configuração é mais difícil para um intruso desativar enquanto é mais fácil de instalar e manter.

 

  • Consumidores

O NB-IoT fornecerá dispositivos portáteis com sua própria conectividade de longo alcance, o que é particularmente benéfico para rastreamento de pessoas e animais. Da mesma forma, NB-IoT também pode ser usado para monitorar a saúde daqueles que sofrem de condições crônicas ou relacionadas à idade.

 

  • Agrícola e Ambiental

A conectividade NB-IoT oferecerá aos agricultores possibilidades de rastreamento, de modo que um sensor contendo o módulo NB‑IoT possa enviar um alerta se o movimento de um animal for fora do comum. Esses sensores poderiam ser usados ​​para monitorar a temperatura e a umidade do solo e, em geral, monitorar os atributos da terra, poluição, ruído, chuva, umidade, pressão, vento etc.

 

Conclusão

O tipo de tecnologia, seja Lora, Sigfox ou NB-IOT, irá depender muito do tipo de projeto e da rede que deverá ser utilizada ou construída para as aplicações de Internet das Coisas. Por exemplo, se eu não sou uma operadora e vou atender um shopping, partiria para o Lora, mas se sou uma rede de farmácias que precisa executar a leitura de umidade e temperatura das geladeiras de remédios, estaria estabelecendo o uso do Sigfox ou NB-IoT. Não que o Lora não seja possível, mas com o Sigfox e NB-IoT teríamos uma infraestrutura muito menor, que se traduz a menores custos e rapidez na implantação. Boa parte dos sensores podem implementar as 3 tecnologias.

 

Bibliografia

Narrowband – Internet of Things (NB-IoT)

 

https://www.rohde-schwarz.com

 

O Protocolo Sigfox

Sigfox é uma solução de baixo custo, confiável, de baixa potência de transmissão para conectar sensores e dispositivos, principalmente visando o mundo de IoT e a nova Indústria 4.0. O protocolo Sigfox concentra-se em:

  • grande autonomia com baixo consumo de energia, permitindo anos de vida útil da bateria;
  • simplicidade na configuração, solicitação de conexão ou sinalização;
  • baixo custo de hardware utilizado nos dispositivos para uma rede, onde se pode otimizar sistemas para serem o mais rentável possível;
  • utiliza pequenas mensagens e apenas pequenas notificações;
  • graças ao seu baixo custo e facilidade de configuração, pode-se também usar o Sigfox como uma solução secundária para qualquer outro tipo de rede, como por exemplo Wi-Fi, Bluetooth, GPRS etc.

A rede Sigfox possui uma arquitetura horizontal, conforme figura 1, composta por duas camadas principais.

 

Arquitetura da rede Sigfox
Figura 1 – Arquitetura da rede Sigfox

 

A primeira camada é a de equipamento de rede, que consiste essencialmente de estações bases (e outros elementos como, por exemplo, antenas) encarregadas de receber mensagens de dispositivos e transferi-las para os Sistemas de Suporte da Sigfox.

O Sigfox Support System é a segunda camada que constitui a rede principal encarregada de processar as mensagens e envia-las por meio de chamadas de retorno para o sistema do cliente. Esta camada fornece também o ponto de entrada para os diferentes atores do eco-sistema (Sigfox, operadores Sigfox, canais e clientes finais) para interagir com o sistema através de interfaces web ou APIs. Esta camada também inclui módulos e recursos que são essenciais para garantir a implantação, operação e monitoramento da rede, como o Business Support System para pedidos e faturamento, o Radio Planning, a implantação da rede e o monitoramento para garantir o bom funcionamento da rede. Além disso, esta camada inclui repositório e ferramentas para analisar os dados coletados ou gerados pela rede.

 

Entendendo a tecnologia Sigfox

 

Rede de serviços Sigfox

Figura 2 – Rede de serviços Sigfox

 

Algumas empresas na Europa, EUA, ou mesmo no Brasil, já estão criando uma rede para comunicação com Sigfox. Se um cliente tem um dispositivo que se comunica usando outras redes, o dispositivo pode já ser compatível com Sigfox, conforme requisitos da rede. Se não, será possível construir, certificar e conectar este dispositivo.

Seguem algumas etapas para se inscrever em uma rede Sigfox.

  • A rede Sigfox é global e gerida por operadores Sigfox locais (SO).
  • A contratação de um SO concede-lhe acesso:
    • à rede pública Sigfox;
    • à nuvem Sigfox, onde você pode ver e gerenciar todos os seus dispositivos na rede;
    • à plataforma de suporte Sigfox, disponível 24/7 para fácil solução de problemas enquanto se desenvolve um produto.

 

Visão geral da rede

A rede Sigfox funciona com mensagens leves (12 bytes, excluindo-se os cabeçalhos de carga). O ciclo de vida de uma mensagem Sigfox é sempre o mesmo:

  • um dispositivo “acorda” e emite uma mensagem usando sua antena de rádio;
  • várias estações base Sigfox na área recebem a mensagem;
  • estações base enviam a mensagem para a nuvem Sigfox;
  • a nuvem Sigfox envia a mensagem para a plataforma backend do cliente.

 

Rede de mensagens Sigfox
Figura 3 – Rede de mensagens Sigfox

 

O que é uma estação base Sigfox?

As estações de base são antenas Sigfox locais, encarregadas de receber mensagens de dispositivos emissores e encaminhá-las para a nuvem Sigfox. Elas são implantadas no campo pelos operadores locais (SO).

São compostas por três elementos principais:

  • uma antena, para receber mensagens pelo ar, geralmente implantada em pontos altos ou torres;
  • um LNA ou LNAC (amplificador de baixo ruído), para amplificar o sinal e o filtrar o ruído;
  • um ponto de acesso, que recebe as mensagens e as envia para a nuvem Sigfox.

Uma vez conectadas, se tornam parte de uma rede pública e começam a ouvir todas as mensagens Sigfox enviadas por dispositivos na vizinhança.

 

Cobertura

Sigfox é uma rede pública, o que significa que os dispositivos vão depender da infraestrutura implantada pelo operador local para se comunicar. A cobertura pública completa pode ser encontrada em: https://www.sigfox.com/en/coverage.

Os operadores também desenvolveram diversas gamas de soluções para cobrir todas as necessidades de uso, tais como:

  • conectividade como um serviço (CAAS) – se o seu negócio está localizado em um país onde está implantado Sigfox, mas sua área ainda não está coberta, pode-se alugar estações base Sigfox, hospedar seu próprio ponto de acesso e estender a rede Sigfox de uma forma simples, flexível e econômica;
  • SDR dongle – se é um fabricante de dispositivos localizados em uma área onde Sigfox ainda não está presente, pode-se comprar um dongle Sigfox SDR, que permite emular localmente uma rede Sigfox para testar e integrar os dispositivos.

As faixas de frequências utilizada no padrão Sigfox são apresentadas na figura 4, ou seja, utilizam-se frequências na faixa de MHz de forma que a área de cobertura seja bem significativa para o envio de mensagens de baixa capacidade, na faixa de bps. Neste caso, é possível alcançar, em campo aberto, algumas dezenas de quilômetros por estação rádio base. Imaginem as perspectivas de novos negócios que podem ser criadas tanto no campo como na cidade.

 

Faixas de frequências do Sigfox
Figura 4 – Faixas de frequências do Sigfox

 

O Sigfox está usando 192 kHz da banda disponível publicamente para trocar mensagens no ar. A modulação é a banda Ultra-Narrow, onde cada mensagem tem 100 Hz de largura e é transferida com uma taxa de dados de 100 ou 600 bits por segundo, dependendo da região. O acesso aleatório é um recurso importante para obter uma alta qualidade de serviço, uma vez que a transmissão não está sincronizada entre a rede e o dispositivo. O dispositivo emite uma mensagem em uma frequência aleatória e, em seguida, envia duas réplicas em diferentes frequências e tempo, que é chamado de “diversidade de tempo e frequência”, conforme a figura 5.

 

Salto em frequência com réplicas
Figura 5 – Salto em frequência com réplicas

 

Uma mensagem com uma carga útil de 12 bytes leva 2,08 s pelo ar com uma taxa de 100 bps. As estações base Sigfox monitoram o espectro completo de 192 kHz e procuram sinais UNB para demodular.

O princípio da recepção cooperativa é que um objeto não está ligado a uma estação base específica, ao contrário dos protocolos celulares, uma vez que a mensagem emitida é recebida por quaisquer estações base que estejam próximas e, em média, o número de estações base é 3 (três). Isso é chamado de “diversidade espacial”.

 

Recepção das mensagens por múltiplas estações base Sigfox
Figura 6 – Recepção das mensagens por múltiplas estações base Sigfox

 

Diversidade espacial associada à diversidade temporal e de frequência das repetições são os principais fatores por trás da alta qualidade de serviço da rede Sigfox.

 

Pequenas mensagens

Para resolver as restrições de custo e autonomia de objetos remotos, no Sigfox, projetou-se um protocolo de comunicação para pequenas mensagens. O tamanho da mensagem vai de 0 a 12 bytes. Uma carga útil de 12 bytes é suficiente para transferir dados do sensor, o status de um evento como um alerta, coordenadas de GPS ou até mesmo dados de aplicativos.

Listamos alguns exemplos de tamanho de carga útil na figura 7.

 

Tamanho de carga útil
Figura 7 – Tamanho de carga útil

 

O regulamento na Europa afirma que podemos ocupar a faixa pública 1% do tempo, o que se traduz em 6 mensagens de 12 bytes por hora ou 140 mensagens por dia. Para mensagens de downlink, o tamanho da carga é estático: 8 bytes, o que é suficiente para acionar uma ação, gerenciar um dispositivo ou definir parâmetros de aplicativo remotamente.

O ciclo de serviço para a estação base é de 10%, o que garante 4 mensagens de downlink por dispositivo por dia. Se houver recursos extras, o dispositivo poderá receber mais.

 

Conclusão

Iremos tratar em artigos futuros um pouco mais do Sigfox comparando com o Lora, já explanado em artigo anterior (veja aqui). Muitos equipamentos sensores e atuadores já estão saindo de fábrica preparados para trabalhar não só com o Lora, mas também com o Sigfox, o que permite novas funções e controles para automação predial, cidades inteligentes ou mesmo para controles diversos na agropecuária, o que vem ao encontro da Indústria 4.0. O futuro já está aí e as oportunidades também.

 

Bibliografia

https://build.sigfox.com/steps/sigfox

 

O Protocolo CoAP para IoT

Já falamos um pouco sobre o protocolo CoAP (Constrained Application Protocol – Protocolo de Aplicação Restrita) para a IoT (Internet of Things – Internet das coisas) aqui. Agora, neste artigo, voltamos com mais detalhes sobre esse protocolo definido pela RFC 7252.

O CoAP é um protocolo de transferência web especializado para uso com nós restritos em redes da Internet das Coisas. O protocolo é projetado para M2M (de máquina-para-máquina), como, por exemplo, aplicações em energia inteligente e automação predial.

O modelo de interação do CoAP é semelhante ao modelo cliente/servidor do protocolo HTTP. No entanto, as interações máquina-máquina normalmente resultam em uma implementação do CoAP que atua nas funções do cliente e do servidor.

Um pedido CoAP é equivalente ao do HTTP e é enviado por um cliente para solicitar uma ação (usando um Código de Método) em um recurso (identificado por uma URI) em um servidor. O servidor envia uma resposta com um código, sendo que esta resposta pode incluir uma representação de recursos.

Ao contrário do HTTP, o CoAP lida com esses intercâmbios de forma assíncrona ao longo de um transporte orientado a datagramas, como o UDP. Isso é feito logicamente usando uma camada de mensagens que suporta uma confiabilidade opcional (com back-off exponencial). O CoAP define quatro tipos de mensagens:

  • confirmação;
  • não confirmação;
  • reconhecimento;
  • reset.

O protocolo CoAP se posiciona, na arquitetura TCP/IP, entre as camadas de Aplicação e Transporte, criando duas subcamadas – Requisição/Resposta e Mensagem, conforme figura 1.

 

Posição do protocolo CoAP na Arquitetura TCP/IP
Figura 1 – Posição do protocolo na Arquitetura TCP/IP

 

Modelo de Mensagens

O modelo de mensagens CoAP baseia-se na troca de mensagens UDP entre os pontos finais, sendo que o CoAP usa um pequeno cabeçalho binário de comprimento fixo (4 bytes) que pode ser seguido de opções binárias compactas e uma carga útil. Este tipo de mensagem compartilha tanto as solicitações como as respostas.

Cada mensagem contém um identificador (ID) de mensagem usado para detectar duplicatas e para uma confiabilidade opcional. O ID da mensagem é compacto e seu tamanho de 16 bits permite até cerca de 250 mensagens por segundo, de um ponto final para outro, estabelecendo parâmetros desta conexão.

A confiabilidade é fornecida marcando uma mensagem como confirmável (CON). Uma mensagem confirmável, figura 2, é retransmitida usando um tempo limite padrão entre retransmissões, até o destinatário, enviando uma mensagem de confirmação (ACK) com o mesmo ID de mensagem.

 

Figura 2 – Transmissão de uma mensagem confiável
Figura 2 – Transmissão de uma mensagem confiável

 

Quando um destinatário não é capaz de processar uma mensagem como confirmável (não é capaz de fornecer uma resposta de erro adequada), ele responde com uma mensagem Reset (RST) em vez de um reconhecimento (ACK).

Uma mensagem que não requer transmissão confiável (por exemplo, uma única medida fora de um fluxo de dados de um sensor) pode ser enviada como uma mensagem não confirmável (NON). Estas não são reconhecidas, mas ainda têm um ID de mensagem para detecção duplicada (neste exemplo, 0x01a0, figura 3). Quando um destinatário não for capaz de processar uma mensagem não confirmável, pode-se responder com uma mensagem Reset (RST).

 

Figura 3 - Transmissão de mensagem não confirmável
Figura 3 – Transmissão de mensagem não confirmável

 

Como o CoAP é executado sobre UDP, que é um protocolo não confiável, também suporta o uso dos endereços multicast IP de destino, permitindo solicitações multicast CoAP, como precaução para evitar o congestionamento da resposta.

Vários modos de segurança são definidos para CoAP, que vão desde sem segurança para segurança baseada em certificados. A RFC especifica uma ligação ao DTLS para garantir o protocolo. O uso do IPsec com o CoAP também é discutido na RFC em [IPsec-CoAP].

 

Modelo de Solicitação/Resposta

A solicitação de CoAP e a semântica de resposta são realizadas nas mensagens do CoAP, que incluem um Código de Método ou Código de Resposta, respectivamente.

Informações de solicitação e resposta opcionais (ou padrão), como a URI, e tipo de mídia de carga são transportados como opções CoAP. Um Token é usado para corresponder as respostas aos pedidos, independentemente das mensagens subjacentes. (Observe que o Token é um conceito separado a partir da identificação da mensagem.)

Uma mensagem de pedido a um determinado elemento da IoT é enviada como confirmável (CON) ou não-confirmável (NON) e, se disponível imediatamente, a resposta a um pedido é também transportada em uma mensagem de confirmação (ACK), conforme figura 4. Isso é chamado de resposta piggybacked. (Não há necessidade de reconhecimento de uma das respostas encaminhadas, uma vez que o cliente irá retransmitir o pedido, se a mensagem de resposta for perdida). Na figura 4, temos dois exemplos para um pedido GET básico de um determinado valor de temperatura em um sensor, com uma resposta, mostrando o caso bem-sucedido com o retorno de 22,5ºC e um caso com erro ou resultando em uma resposta 4.04 (não encontrada).

 

Figura 4 – Dois pedidos GET com respostas encadeadas
Figura 4 – Dois pedidos GET com respostas encadeadas

 

Se o servidor não puder responder imediatamente a uma solicitação realizada em uma mensagem confirmável, ele simplesmente responde com um vazio de mensagem de confirmação para que o cliente possa parar de retransmitir o pedido. Quando a resposta está pronta, o servidor envia-o em uma nova mensagem confirmável (que, por sua vez, deve ser reconhecida pelo cliente). Isso é chamado de “resposta separada”, como ilustrado na figura 5.

 

Figura 5 – um pedido GET com uma resposta separada
Figura 5 – um pedido GET com uma resposta separada

 

Se uma solicitação for enviada em uma mensagem não confirmável, a resposta é enviada usando uma nova mensagem não confirmável, embora o servidor possa, em vez disso, enviar uma mensagem confirmável. Esse tipo de troca é ilustrado na figura 6.

 

Figura 6 – Um pedido e uma resposta realizada em mensagens não confirmáveis
Figura 6 – Um pedido e uma resposta realizada em mensagens não confirmáveis

 

O CoAP faz uso de métodos GET, PUT, POST e DELETE de forma semelhante ao HTTP. A semântica detalhada dos métodos CoAP possui algumas diferenças dos métodos HTTP. Para quem vai trabalhar com este protocolo, vale a pena ler a RFC para maior detalhamento e as diferenças em relação ao HTTP.

Além dos quatro métodos básicos mencionados anteriormente, podem ser adicionados ao CoAP, em separado, novos métodos que não precisam necessariamente usar pedidos e respostas em pares. Mesmo para os métodos existentes, um único pedido pode produzir respostas múltiplas, por exemplo, para um pedido de multicast  com a opção Observe (Observe especifica uma extensão de protocolo simples para CoAP que permite aos clientes do CoAP “observar” os recursos, ou seja, recuperar uma representação de um recurso e manter esta representação atualizada pelo servidor durante um período de tempo).

O suporte a URI em um servidor é simplificado, já que o cliente já analisa o URI e o divide em componentes de host, porta, caminho e consulta, fazendo uso de valores padronizados. Os códigos de resposta se relacionam para um pequeno subconjunto de códigos de status HTTP com alguns códigos específicos do CoAP.

 

Conclusão

Do ponto de vista do desenvolvedor, o CoAP se parece muito com o HTTP. Obter um valor de um sensor de pressão, temperatura, entre outros, não é muito diferente de obter um valor de uma API da Web.

Como o HTTP e o CoAP compartilham o modelo REST, eles podem ser facilmente conectados usando proxies inter-protocolos independentes do aplicativo. Um cliente da Web pode nem sequer perceber que ele acessou apenas um recurso de sensor.

 

Bibliografia

RFC 7252 – The Constrained Application Protocol (CoAP) – IETF Tools

 

Como o Protocolo IP Pode Ajudar a Reduzir Custos no Seu Condomínio

Nesta época de crise, de mudanças na legislação trabalhista, buscam-se novas tecnologias para redução de custos e maiores controles. Neste cenário, recebi uma demanda de leitores sobre a possibilidade do uso da Internet e do protocolo IP para construção de uma solução de portaria virtual, ou seja, exclui-se a figura do porteiro local e cria-se uma posição remota onde um porteiro de uma empresa de vigilância terceirizada possa controlar até 5 condomínios simultaneamente. Obviamente isto deve reduzir muito o custo para os condomínios residenciais, sejam verticais ou horizontais. Não será considerada aqui a segurança física ou a operação do processo, uma vez que o intuito é discutir como a tecnologia IP e a Internet podem viabilizar este tipo de comunicação e controle.

Antes de propor uma ideia tecnológica, é importante entender o modo de operação de um condomínio simples sem tecnologia, com sistema de clausura e intertravamento:

  1. o porteiro identifica o morador e abre o primeiro portão, e neste caso o morador fica na clausura;
  2. o porteiro abre o segundo portão, que só pode ser aberto caso o primeiro portão esteja fechado (intertravamento), e o morador entra;
  3. o porteiro recebe um visitante e liga para a unidade que autoriza ou não a liberação da entrada; se houver liberação, o primeiro portão é aberto;
  4. o porteiro identifica o visitante por meio de RG, registra em livro e abre o segundo portão para o visitante entrar.

Um porteiro custa a um condomínio, dependendo da empresa, algo entre R$ 15.000,00 e R$ 20.000,00. Com a portaria virtual, este valor pode cair para algo entre R$ 6.000,00 e R$ 8.000,00. Obviamente toda a operação deve ser modificada, bem como o engajamento de todos os moradores, para se ter um nível de segurança aceitável, o que justifica a instalação apenas em condomínios de até 40 ou 50 unidades, ou seja, um porteiro virtual poderá atender até 250 unidades simultaneamente.

Como tratar a tecnologia IP neste cenário? Ela acabou sendo uma alternativa fantástica, viável e de baixo custo para viabilizar este novo cenário que vem crescendo de forma exponencial no Brasil.

Características que posso afirmar em relação a rede IP, mais especificamente a Internet:

  • é uma rede que funciona muito bem;
  • de grande resiliência;
  • de alta capilaridade;
  • permite qualidade de serviço por meio de MPLS e mecanismos de QoS;
  • garante segurança por meio de aplicações baseadas em VPN (Redes Virtuais Privadas) e IPSec;
  • é de baixo custo.

Desta forma, vou redesenhar nosso modo de operação com vista ao mundo IP e a Internet.

Nesse cenário, tem-se:

  1. a portaria virtual, com um porteiro real mais um monitor para visualização das imagens da portaria de um condomínio, e o controle remoto para abertura e fechamento dos portões;
  2. um bom acesso à rede pública IP (concessionária ou provedores de serviço);
  3. um PABX IP para viabilizar o tráfego de voz sobre IP ou VoIP;
  4. um banco de FXS para interconectar os ramais analógicos sem a necessidade de alteração da infraestrutura do condomínio, o que inviabilizaria a instalação em um primeiro momento, ou seja, o banco de FXS faz a conversão de um ramal IP para um ramal analógico;
  5. um interfone IP;
  6. um NVR (Network Video Recorder) + câmeras IP para a visualização remota;
  7. um sistema de controle local para abertura de portões com acesso via Internet.

Pronto, está definido e vamos detalhar esta ideia.

A figura 1 apresenta um visitante chegando a um condomínio e acessando o interfone IP. Este interfone IP tem uma interface Ethernet, um endereço IP que está ligado a uma porta de um switch no interior do condomínio, que está registrado em um servidor SIP (PABX IP), também no interior do condomínio.

 

Fase 1 da comunicação - portaria virtual
Figura 1 – Fase 1 da comunicação

 

A portaria virtual entra em contato com o condômino, figura 2,  via SIP (protocolo de sinalização de voz), controlado pelo PABX IP  e transporte da voz codificada com compressão por meio de codificadores como o G.729 de boa qualidade, que autoriza ou não a entrada desse visitante.

Todas as chamadas ficam gravadas no PABX IP e o acesso só é feito com a liberação do morador.

 

Fase 2 da comunicação - portaria virtual
Figura 2 – Fase 2 da comunicação

 

A portaria virtual retorna o acesso ao visitante, figura 3, ou prestador com acesso positivo ou negativo para sua entrada.

 

Fase 3 da comunicação - portaria virtual
Figura 3 – Fase 3 da comunicação

 

A portaria virtual habilita remotamente via Internet, figura 4, a entrada do visitante ou prestador de serviços por meio de portas com chaves magnéticas.

 

Fase 4 da comunicação - portaria virtual
Figura 4 – Fase 4 da comunicação

 

Finalizando a ideia, temos a figura 5 que retrata com mais detalhe como a tecnologia IP pode ajudar neste novo cenário que começa a ser desenhado.

 

Detalhe do sistema proposto - portaria virtual
Figura 5 – Detalhe do sistema proposto

 

No desenho da figura 5 tem-se um sistema com uma placa controladora de porta que pode ser acessado via Internet, com alimentação PoE (Power over Ethernet) para abertura de duas fechaduras magnéticas, com controle biométrico, para o caso de moradores e intertravamento.

Da mesma forma, em cada porta tem-se um conjunto de câmeras IP tipo HD (alta definição) com, no mínimo, 2 MP, ligadas a um switch ou às portas ethernet PoE do NVR. Boa parte dos equipamentos NVR possuem, ainda, entradas digitais que permitem monitorar os sistemas de cerca elétrica e infravermelho perimetral que irão notificar o porteiro remoto ou virtual.

Caso o visitante conheça a unidade, poderá chamar diretamente um condômino que também poderá habilitar o acesso ao visitante. Para maior segurança, os sinais das câmeras IP podem ser compartilhados na antena coletiva do condomínio, de modo que cada morador possa acompanhar este acesso da televisão da sua residência.

Como se trata de comunicação de voz, é importante contratar da operadora uma boa conexão à Internet com garantia de qualidade, no caso da voz e vídeo, segurança baseada em VPN IPSec com a utilização de caminhos baseados em rótulos ou MPLS do condomínio até a central de monitoração. Para garantir uma banda suficiente para transmissão de áudio e vídeo, sugere-se, no mínimo, um acesso com garantia de 8 Mbps considerando as imagens das câmeras de alta definição, do transporte de voz e controle de abertura dos portões.

Como o sistema fica muito dependente da Internet, sugere-se também a contratação de um segundo link de acesso à Internet de outra operadora, como segurança no caso da queda do primeiro link, na mesma taxa, e mecanismos automáticos no roteador no interior do condomínio como, por exemplo, o HSRP (Hot Standby Router Protocol).

 

Conclusão:

Há alguns anos, já se falava de redes convergentes, ou seja, todos os sistemas de comunicação, voz, vídeo ou dados, iriam convergir para o transporte via IP. Rapidamente esta ideia vem se concretizando em todos os meios, chegando com força ao controle residencial, condominial, predial comercial ou industrial.

Com a ampliação da comunicação via celular, novas tecnologias de controle de acesso vêm ganhando espaço, como o NFC (Near Field Communication) que representa um conjunto de padrões para comunicação por radiofrequência criado para transferência de dados entre o celular e outros equipamentos, conforme figura 6, que poderão também complementar nossa solução.

 

Acesso via NFC
Figura 6 – Acesso via NFC

 

Protocolos Envolvidos na IoT

Trabalha-se para definir um modelo ou arquitetura para a IoT (Internet of Things – Internet das Coisas), mas já existem alguns protocolos que estão na vanguarda desta tecnologia. São os protocolos CoAP, MQTT, XMPP e AMQP.

Neste artigo, estaremos apresentando, de forma resumida, a função de cada um destes protocolos para que possamos tratar mais profundamente os elementos sensores, o transporte de informação e a atuação de elementos por meio de aplicações.

 

CoAP (Constrained Application Protocol)

CoAP (Constrained Application Protocol – Protocolo de Aplicação Restrita), definido pela RFC 7252, é um protocolo de transferência Web especializado para uso com nós restritos e redes na Internet das Coisas. O protocolo é projetado para M2M (de-máquina-para-máquina), como, por exemplo, aplicações em energia inteligente e automação predial.

Como o HTTP, o CoAP é baseado no modelo REST: servidores disponibilizam recursos em um URL e os clientes acessam esses recursos usando métodos como GET, PUT, POST e DELETE.

Do ponto de vista do desenvolvedor, o CoAP se parece muito com o HTTP. Obter um valor de um sensor de pressão, temperatura, entre outros, não é muito diferente de obter um valor de uma API da Web.

Como o HTTP e o CoAP compartilham o modelo REST, eles podem ser facilmente conectados usando proxies inter-protocolos, independentes do aplicativo. Um cliente da Web pode nem sequer perceber que ele acessou apenas um recurso de sensor.

Como o HTTP, o CoAP pode carregar diferentes tipos de cargas úteis e pode identificar qual tipo de carga útil está sendo usado. CoAP integra-se com XML, JSON, CBOR, ou qualquer formato de dados de sua escolha.

A Internet das Coisas precisará de bilhões de nós, muitos dos quais precisam ser baratos. CoAP foi projetado para trabalhar com microcontroladores com baixa capacidade de memória como 10 KiB de RAM e 100 KiB de espaço de código (RFC 7228).

O CoAP foi projetado para usar recursos mínimos, tanto no dispositivo quanto na rede. Em vez de uma pilha de transporte complexa, é encapsulado no UDP e no IP respectivamente.  Um cabeçalho fixo de 4 bytes e uma codificação compacta de opções permite mensagens pequenas que causam pouca ou nenhuma fragmentação na camada de enlace. Muitos servidores podem operar de uma forma completamente sem estado, além de permitir um diretório de recursos que fornece uma maneira de descobrir as propriedades dos nós em sua rede.

Este protocolo foi projetado para durar décadas, principalmente levando em conta o controle de congestionamento usando o estado da arte.

Em relação à segurança, o CoAP utiliza parâmetros DTLS, que é equivalente a chaves RSA de 3072 bits, funcionando bem nos menores nós.

 

MQTT (Message Queue Telemetry Transport)

O MQTT é um protocolo de conectividade de-máquina-para-máquina (M2M) também utilizado em Internet das Coisas. Foi projetado para ser extremamente leve e publicar/subscrever o transporte de mensagens. É útil para conexões remotas com pequena largura de banda, como é o caso de informações extraídas de sensores. Por exemplo, tem sido utilizado em sensores que se comunicam por meios físicos via satélite ou numa gama de domótica e cenários de dispositivos pequenos. Também é ideal para aplicações móveis devido ao seu pequeno tamanho, baixo consumo de energia, pacotes de dados minimizados e distribuição eficiente de informações para um ou mais receptores.

O MQTT foi projetado para redes de baixa largura de banda e alta latência no final da década de 1990/início de 2000. Como resultado, os designers fizeram uma série de escolhas fundamentais que influenciaram a forma como “olha e sente”, além de fornecer um sólido bloco de construção que pode ser facilmente integrado em outras soluções.

É útil para a maioria das aplicações de sensor e permite que os dispositivos fiquem online e publiquem “material” que não tenha sido previamente conhecido ou predefinido.

Arquitetura:

  • MQTT tem um modelo cliente/servidor, onde cada sensor é um cliente e se conecta a um servidor, conhecido como um agente (broker), sobre TCP.
  • MQTT é orientado a mensagem. Cada mensagem é um pedaço discreto de dados, opaco para o agente.
  • Cada mensagem é publicada para um endereço, conhecido como um tópico. Os clientes podem assinar vários tópicos. Cada cliente inscrito em um tópico recebe todas as mensagens publicadas no tópico.

Exemplo:

Imagine uma rede simples com três clientes e um agente central. Todos os três clientes abrem conexões TCP com o agente. Os Clientes B e C subscrevem a temperatura do tópico, como mostra a figura 1.

 

Exemplo Protocolo MQTT
Figura 1 – Exemplo Protocolo MQTT

 

Posteriormente, o Cliente A publica um valor de temperatura de  22,5 ºC para a temperatura do tópico. O agente encaminha a mensagem para todos os clientes inscritos, como na figura 2.

 

Exemplo Protocolo MQTT
Figura 2 – Exemplo Protocolo MQTT

 

O modelo de assinante permite que clientes MQTT comuniquem-se de um-para-um, um-para-muitos e muitos-para-um.

 

XMPP (Extensible Messaging and Presence Protocol)

O XMPP é um protocolo para streaming de elementos XML (Extensible Markup Language), a fim de trocar mensagens e informações de presença em tempo aproximado. O principal recurso do XMPP é: Core [XMPP-CORE]. Esse recurso, principalmente os fluxos de XML, fornecem os blocos de construção para muitos tipos de eventos, quase reais, que podem ser colocados em camadas no topo do núcleo enviando dados específicos do aplicativo qualificados por espaços de nomes XML específicos [XML-NAMES].

É um protocolo de comunicação para middleware orientado a mensagens, baseado em XML. Permite o intercâmbio em tempo quase real de dados estruturados, porém extensíveis, entre quaisquer duas ou mais entidades de rede. Originalmente chamado Jabber, o protocolo foi desenvolvido pela comunidade de código aberto Jabber em 1999 para mensagens instantâneas em tempo real (IM), informações de presença e manutenção de listas de contatos. Projetado para ser extensível, o protocolo tem sido usado também para sistemas de subscrição de publicação, sinalização para VoIP, vídeo, transferência de arquivos, jogos etc.

Ao contrário da maioria dos protocolos de mensagens instantâneas, o XMPP é definido em um padrão aberto e usa uma abordagem de sistemas abertos de desenvolvimento e aplicação, através da qual qualquer pessoa pode implementar um serviço XMPP e interoperar com implementações de outras organizações. As implementações podem ser desenvolvidas usando qualquer licença de software. Embora muitas implementações de servidor, cliente e biblioteca sejam distribuídas como software livre e de código aberto, também existem numerosas implementações de software comercial.

 

AMQP (Advanced Message Queuing Protocol)

AMQP é um padrão aberto para passar mensagens de negócios entre aplicativos ou organizações. Ele conecta sistemas, alimenta os processos de negócios com as informações de que eles precisam, transmitindo de forma confiável as instruções que atingem seus objetivos, criando interoperabilidade entre clientes e intermediários (ou seja, middleware de mensagens). O objetivo é permitir que uma ampla gama de diferentes aplicações e sistemas sejam capazes de trabalhar em conjunto com mensagens padronizadas em escala industrial.

O AMQP inclui definições tanto para a forma como a rede deve funcionar, como para a forma que os aplicativos de mensagens de agente funcionam. Isto significa que as especificações são para:

  • operações de roteamento e armazenamento de mensagens;
  • definir um conjunto de regras de funcionamento dos componentes envolvidos;
  • implementar como as comunicações entre os clientes e os agentes que executam as operações funcionam.

 

Conclusão:

A Internet das Coisas concebeu um sistema de sensores onipresentes conectando o mundo físico à Internet. Embora as coisas, a Internet e a conectividade sejam os três componentes principais da IoT, ainda é necessário trabalhar as lacunas entre os mundos físico e digital. Vamos estar atentos às oportunidades que esta tecnologia irá nos proporcionar.

 

Bibliografia

http://coap.technology/

https://eclipse.org/community/eclipse_newsletter/2014/february/article2.php

https://xmpp.org/rfcs/rfc3921.html

https://www.amqp.org/

 

O Protocolo KNX

Em artigos anteriores, apresentamos a tecnologia IoT ou Internet das Coisas, bem como a capacidade de controle de dispositivos utilizando a mobilidade com as redes sem fio e o protocolo IP. Pode-se, neste contexto, atentar para os diversos elementos de rede existentes em um prédio inteligente considerando um protocolo que vem ganhando cada vez mais adeptos no Brasil que é o protocolo KNX.

O protocolo KNX é um padrão aberto para todas as aplicações de domótica, abarcando desde a iluminação e controle de elementos de automação predial padronizando a interconexão de diversos sistemas como segurança, aquecimento, ventilação, ar condicionado, monitoração, alarme, controle de água, eficiência energética, eletrodomésticos, som, entre outros. A tecnologia pode ser utilizada em edifícios residenciais e não residenciais novos e já existentes.

A figura 1 apresenta a versatilidade do protocolo, uma vez que se trata de um sistema aberto com possibilidade para “conversar” com demais protocolos do mundo IP ou do mundo de automação industrial, como o Modbus, BACnet, CAN etc.

 

Figura 1 – Controles do sistema do protocolo aberto KNX para ambiente predial (fonte: http://eurodomotica-knx.com.br/br/knx/)

 

É uma tecnologia flexível que pode ser implementada em qualquer plataforma de processadores com o uso de dispositivos de uma série de fabricantes na área de domótica, que tem crescido rapidamente no Brasil.

O KNX é um protocolo global para domótica que considera:

O KNX está aprovado nas comissões europeias e americanas como:

  • norma europeia (CENELEC EN 50090 e CEN EN 13321-1);
  • norma internacional (ISO/IEC 14543-3);
  • norma chinesa (GB/T 20965); e
  • norma dos EUA (ANSI/ASHRAE 135).

Ferramenta KNX – o ETS

ETS significa Software Engineering Tool: é uma ferramenta independente para projetar e configurar instalações como casas e edifícios para permitir o controle inteligente com o sistema KNX.

ETS é um software que funciona em computadores baseados em plataforma Windows © para apoio na realização de projetos de automação predial nas seguintes fases e tarefas:

  • projeto de planejamento e design;
  • comissionamento;
  • documentação de projeto;
  • diagnóstico e solução de problemas.

As áreas de aplicação incluem:

  • controle de iluminação (comutação, dimerização, “iluminação ambiente”);
  • controle de sombreamento (persianas, cortinas);
  • aquecimento, ventilação, ar condicionado (sala de controle individual de temperatura, controle de radiadores, unidades térmicas, caldeiras, coolers, ventiladores, …);
  • acesso e segurança (detecção de presença, detecção e alarme de roubo e de incêndio, simulação de presença, interruptor de pânico);
  • gestão de energia (consumo de medição, corte de carga, …);
  • funções de conforto e controle inteligente em todas as aplicações (controle de usuário central, controle de processo inteligente, combinação de cenário …);
  • controle remoto e manutenção remota (por exemplo via telefone ou Internet).
  • interface com sistemas complementares ou periféricos (produtos da linha branca, consoles de supervisão, gestão de instalações, sistemas de segurança dedicados, áudio, multimídia, serviços, …).

O KNX funciona basicamente em barramento, conforme figura 2, o que diminui a grande quantidade de cabos para distribuição dos diversos elementos da rede, onde cada elemento passa ser endereçado enviando e recebendo informações de um processador central.

 

Figura 2 – Barramento da rede KNX                               (fonte: http://www.knx.org/)

 

Na figura 3 tem-se o esquema de ligação de dispositivos KNX.

 

Figura 3 – Esquema de ligação de dispositivos KNX         (fonte: http://www.knx.org/)

 

O protocolo permite em uma visão funcional:

  1. distribuição;
  2. aplicação de modelos para as várias tarefas;
  3. automação (este é, afinal, o objetivo principal do sistema);
  4. configuração e gerenciamento, para gerir adequadamente todos os recursos na rede permitindo a ligação lógica ou ligação de partes de um aplicativo distribuído, que são executados em diferentes nós;
  5. um sistema de comunicação, com um conjunto de meios de comunicação física, um protocolo de mensagem e modelos para a pilha de comunicação em cada nó correspondente;
  6. este sistema de comunicação tem de suportar todos os requisitos de comunicação de rede para a configuração e o gerenciamento de uma instalação, bem como para hospedar aplicativos distribuídos nela (este é tipificado pelo KNX Kernel);
  7. modelos de dispositivos, resumidos em perfis, para a realização eficaz e combinação dos elementos para desenvolver produtos ou dispositivos reais, que serão montados e ligados em uma instalação.

Formato do quadro

Agora é hora de termos um pequeno olhar para o formato real da mensagem KNX, como uma série codificada no quadro enviado no barramento.

A figura 4 apresenta o formato do protocolo.

 

Figura 4 – Quadro de informação do protocolo KNX

 

 

O Campo de Controle determina a prioridade de quadro e distingue entre o padrão e uma versão estendida.

O campo Endereço pode ser de um para um (unicast) ou grupo (multicast).

A Contagem de saltos do quadro é decrementada pelos roteadores para evitar looping das mensagens. Quando se torna zero, o quadro é descartado a partir da rede, assim como acontece com o campo TTL do protocolo IP.

A TPCI controla as relações de comunicação, camada de transporte, por exemplo, para construir e manter um conexão ponto-a-ponto.

Por sua vez, a APCI completa as ferramentas de serviços de camada de aplicação (ler, escrever, responder, …) que estão disponíveis para o esquema de endereçamento e comunicação de relacionamento. Dependendo do esquema de endereçamento e APCI, o quadro padrão pode transportar até 14 octetos de dados. O protocolo permite a segmentação para transferência em massa, como o download de um programa de aplicação inteira, e é de responsabilidade da gestão do cliente, por exemplo, com o uso de ferramenta ETS.

O quadro padrão assegura a compatibilidade com outros sistemas e o quadro alargado pode abrigar até 248 octetos de dados. Seu uso é definido principalmente para LTE-Mode.

Finalmente, a Checagem do Quadro ajuda a garantir a consistência dos dados e transmissão.

Conclusão:

O KNX é uma mistura coerente de protocolos, interfaces de programação, modelos e ferramentas que estão disponíveis, permitindo explorar e construir soluções que integram a instalação da rede de dispositivos em um ambiente de LAN ou WAN.

As especificações KNX permitem integração com as redes de pacotes IP de forma flexível, uma vez que é possível encapsular o quadro KNX sobre um trecho IP. Existem também implementações deste protocolo, sob a forma de comunicadores iETS (ETS Internet), que permitem a manutenção remota de KNX nas instalações.

Permite a integração com outros sistemas, como:

  • SCADA (Supervisão, Controle e Aquisição de Dados Automatizado), por exemplo, via OPC (OLE for Process Control);
  • gateways de serviço remoto, por exemplo, via OSGi;
  • ambientes de rede locais ou remotos, intranet, extranet e aplicações de internet, sistematicamente por meio de protocolos baseados em IP (Internet Protocol);
  • específicos para estabelecimento de padrões em automação predial, como BACnet.

O KNX tem surgido como um protocolo importante para integração de elementos de automação aproveitando a capilaridade da rede IP para acessos e controles de forma remota.

 

Bibliografia

http://eurodomotica-knx.com.br/br/knx/

http://www.knx.org

Demonstração Energy Cloud

Com a solução Energy Cloud em automação predial é possível ter comunicação com múltiplos equipamentos e protocolos, proporcionando grande flexibilidade na integração com instalações físicas novas ou já existentes.

Como mostrado no Webinar Energy Cloud – Inteligência Predial, a interface é flexível e organizada numa plataforma em nuvem. As medições são efetuadas e mostradas em tempo real, com visualização de gráficos e informação de consumo. Permite automatizar rotinas por meio de regras e definir situações para o sistema enviar alerta por SMS ou e-mail.

Para conhecer um pouco mais, acesse a demonstração em:

http://demo.energypro.io/

Login: worlddemo
Password: demo

Para implantar a solução Energy Cloud em seu prédio ou condomínio de forma eficiente, de modo a evitar o desperdício de recursos e gerar economia, entre em contato com a Wire Engenharia!

Webinar Energy Cloud – Inteligência Predial

Monitore seu consumo em tempo real e controle seus equipamentos para otimizar o uso de recursos.

Veja a gravação do webinar onde é apresentada a solução Energy Cloud, uma espécie de sistema de gerenciamento predial na nuvem:

Webinar Energy Cloud – Inteligência Predial

Quer implantar a solução Energy Cloud no seu prédio ou condomínio? Entre em contato com a Wire Engenharia!

 

O IP no Mundo da Automação Predial e o RS-485

Temos acompanhando a tecnologia de IoT (Internet das Coisas) e o seu desenvolvimento, mas ainda existem diversos passos para percorrermos até que as tecnologias de comunicação fiquem totalmente IP ou que todas as redes convirjam para a arquitetura IP no que chamamos de redes convergentes. Infelizmente não podemos mudar tudo do dia para a noite, uma vez que envolve não só custos de hardware, mas também horas e horas de trabalho com softwares.

Por que insistimos no “mundo” IP? Porque tem alta capilaridade, chega em qualquer lugar do mundo, é barato, funciona muito bem, pode-se implementar funções de QoS (Qualidade de Serviço), permite altas taxas que podem chegar comercialmente, a Tbps, além de ser uma arquitetura leve e relativamente simples.

Um dos pontos que estaremos discutindo neste artigo, trata dos prédios inteligentes ou automação predial, que vem ao encontro da ideia do IoT, considerando que um prédio pode ser um ponto controlado não só internamente, mas também ser acessível via rede pública IP, que utiliza na maioria dos casos, localmente, o protocolo TIA/EIA 485 na camada física e nas camadas superiores, conforme figura 1, protocolos como o Modbus, BACnet, entre outros.

A norma que especifica o padrão RS-485, no entanto, não especifica o formato nem a sequência de caracteres para a transmissão e recepção de dados. Neste sentido, além da interface, é necessário identificar também o protocolo utilizado para comunicação.

A rede BACnet MS/TP define a troca de mensagens BACnet utilizando o padrão RS-485 como meio físico.

O BACnet e Modbus utilizam o protocolo RS-485 (TIA/EIA-485-A) no modo half-duplex com uma sinalização em 9600, 19200, 38400 e 76.800 baud, em distâncias curtas (<100 pés ou 30 metros).

Uma rede RS-485 pode também utilizar dois pares trançados, operando no modo full-duplex especificando um comprimento máximo de 1200 metros para os cabos de comunicação.

Também é possível, utilizando uma infraestrutura baseada em Ethernet local, que pode ser mais acessível converter para BACnet MS/TP ou Modbus RTU sobre RS-485 e este para TCP/IP BACnet ou Modbus TCP/IP sobre Ethernet.

Pronto, já temos o “mundo” IP entrando no mundo da automação predial com muito sucesso.

O BACnet  foi criado pela Sociedade Americana de Aquecimento, Refrigeração e Ar Condicionado (ASHRAE), onde começou a ser desenvolvido a partir de uma discussão pública no ano de 1987, sendo declarado como um “standard” no mercado em 1995 e, desde então, tem sido apoiado e mantido pela ASHRAE.

BACnet significa Building Automation and Control Networks, que é um meio de integração de sistemas gestão de edifícios com um conjunto de regras para criação de redes interoperáveis, ou seja, é um padrão aceito no mercado interno (ASHRAE/ANSI 135-2004), na Europa (CEN TC 247), e no mundo (ISO 16484-5).

O padrão BACnet, figura 1, define seis tipos de redes de comunicação para transporte de mensagens BACnet. O tipo de rede define a camada física e de enlace. Os seis tipos de redes são:

  • BACnet ARCnet;
  • BACnet Ethernet;
  • BACnet Lontalk;
  • BACnet MS/TP;
  • BACnet Point-to-Point;
  • BACnet IP.
Figura 1 – Arquitetura do protocolo BACnet

 

Vamos discutir o Protocolo BACnet utilizando o padrão RS-485 para as camadas física e de enlace, denominado BACnet MS/TP (Mestre Escravo/Token Passing). As estações BACnet MS/TP podem ser divididas em dois grupos, estações mestre e estações escravas, conforme a faixa de endereço da estação.

A Estrutura das Mensagens no BACnet MS/TP define que o frame pode ter de 0 a 501 bytes (octetos) e cada byte é composto por 8 bits sem paridade com start e stop bit, conforme ilustra a figura 2.

 

Figura 2 – Estrutura do byte

 

Recepção (RX): O tempo máximo entre cada byte (Tframegap) é de 20 bit times. E o tempo mínimo entre frames (Tturnaround) após o stop bit do último byte do frame é 40 bit times, conforme figura 3.

Transmissão (TX): o sinal RTS deve ser desabilitado após (Tpostdrive) 15 bit times depois do envio do stop bit.

 

Figura 3 – Recepção dos dados BACnet

 

O frame de dados BACnet é formado por um cabeçalho (header) e os dados, como ilustra a figura 4.

 

Figura 4 – Frame BACnet

 

Enquanto a velocidade for relativamente baixa e as distâncias relativamente curtas, a influência da topologia da rede em seu desempenho não é significativa. Contudo, quando os efeitos de linhas de transmissão começam a aparecer, há apenas uma topologia simples que permite gerenciar estes efeitos. A figura 5 mostra alguns tipos de topologias. Apenas no tipo “daisy chain”, onde todos os dispositivos são conectados diretamente aos condutores da linha de comunicação principal, controla as reflexões causadoras de erros de comunicação.

 

Figura 5 – Topologia da rede de automação predial baseada em BACnet

 

Isso não significa que não se possa implementar uma rede com outra topologia. Entretanto, na prática, controlar as reflexões em uma rede tipo estrela (por exemplo) é algo um pouco complexo.

Como a automação predial está caminhando para o IP?

Uma rede local, LAN, seja com ou sem fio, permite a ligação em estrela com interconexão por meio de switches posicionados em locais cuja distância não ultrapasse os 90 metros (considerando o padrão de cabeamento estruturado com Categoria 5e, 6 ou 7) ou via fibra óptica, dependendo da taxa, a distâncias que podem chegar a 2 ou mais quilômetros em fibra multimodo.

Os módulos de automação parecem seguir, até um certo ponto, para uma rede baseada em Ethernet com switch ao invés do tradicional sistema em barramento e ficar totalmente compatível com o Ethernet/IP, conforme figura 6.

 

Figura 6 – Rede IP interconectando com uma rede RS-485

 

Mas ainda existem diversos questionamento das empresas que trabalham com automação no sentido da facilidade do uso, endereçamento, economia e ligação das redes em barramento utilizadas hoje ou, em alguns casos, novos módulos que já permitem interface IP/Ethernet conforme a figura 7, ligando por meio de gateways, redes baseadas em RS-485.

 

Figura 7 – Web Services usados para integrar BAS

 

Os Web Services (Serviços Web) tornaram-se rapidamente o padrão para comunicações B2B, desta forma, é natural se perguntar se vão substituir BACnet, LonWorks, ou outros protocolos dentro dos BAS. Isso não é provável, por várias razões que comentaremos a seguir.

Para começar, ninguém desenvolveu um conjunto de serviços da Web que abrange todas as funções necessárias para um barramento como o caso da topologia Daisy Chain, mais utilizada em automação, além do formato de transmissões, alarmes, sincronização de tempo, backup e restauração. Há uma série de funções do BAS que simplesmente não são cobertos no padrão de serviços Web proposto até agora. Certamente tal padrão poderia ser desenvolvido, mas seria em essência mais um protocolo para a aceitação no mercado. Deveria ser um protocolo adequado para um BAS porque os serviços da Web exigem mais “overhead” do que a maioria dos controladores BAS pode proporcionar. Vale lembrar que os serviços da Web usam XML para se comunicar através de uma rede IP como forma para empacotar dados. Estas características também significam que é necessário ser processado por um computador poderoso e transmitidos através de uma rede de alta velocidade. Isto está além das capacidades dos controladores que normalmente são utilizados em equipamentos de automação. Esta pode ser uma limitação temporária uma vez que novos microprocessadores ganham potência e velocidade a cada ano e, principalmente porque já existem protocolos como o BACnet que desenvolveram formas mais eficientes de integração de controladores e estão abertos para utilização por qualquer equipamento ou fabricante uma vez que há muito pouco incentivo para mudar esses controladores para serviços na Web.

Os computadores e as redes têm “potência” para lidar com serviços da Web e provavelmente haverá certa quantidade vinculações, se não for a programação personalizada, necessários para fazer as ligações, mas as características do XML simplificam a tarefa do programador. As chances são de que o programador já esteja familiarizado com os serviços da Web de integrações B2B anteriores, o que simplifica ainda mais o trabalho. A adição de um novo padrão ASHRAE para os serviços da Web promete ainda uma maior simplificação, usando a tecnologia IP e da fundação da BACnet para colocar um edifício no mundo da automação baseado em IP.

Conclusão:

Sistemas de automação baseados em IP estão ganhando impulso, graças aos vários fatores que contribuem com a penetração da Internet nos dispositivos computacionais cada vez mais baratos e suas respectivas plataformas. A tecnologia da informação é uma poderosa ferramenta e as empresas podem efetivamente explorar a infraestrutura existente para integrar sistemas de automação, permitindo o acesso remoto, gerenciamento e controle distribuído.

Por outro lado, a tecnologia IP de próxima geração, o IPv6, permitirá um endereço IP disponível para praticamente todos os elementos de rede, uma vez que o número de dispositivos, aplicações e serviços baseados em tecnologias IP está crescendo exponencialmente, tornando imperativo ter endereços IP suficientes para atender a esta nova demanda.

Relativo ao tipo e os requisitos de aplicação, a construção de softwares ou equipamentos proprietários podem explorar as tecnologias de flexibilidade do IP para realizar a interoperabilidade e convergência. Nota-se que existem muitas vantagens em optar por tecnologias IP, observando o bom uso da infraestrutura de rede. Verifica-se que na maioria dos casos, os utilizadores destas tecnológicas tem muito a contribuir e, portanto, seu conhecimento e perspectiva em relação a segurança da comunicação pode e deve ser reforçada para o benefício do edifício.

 

Bibliografia

http://www.ccontrols.com/pdf/ExtV1N1.pdf

http://www.novus.com.br/

http://www.bacnetinternational.org/