Os fabricantes de hardware têm investido consideravelmente no desenvolvimento de soluções atractivas para a ligação de redes de sensores. Dependendo das necessidades de campo, surgiu uma grande variedade de opções. Existem gateways para áreas de aplicação específicas, como o gateway FlexGate da EXPEMB, otimizado para LoRa. Existem também sistemas multifuncionais, como o gateway conga-IoT da congatec, que oferece até oito antenas de rádio, permitindo uma seleção extremamente diversificada de tecnologias sem fios, bem como a ligação de periféricos e fieldbuses adicionais. No entanto, as plataformas de hardware específicas para cada aplicação são apenas o primeiro passo para uma plataforma de soluções que facilite aos desenvolvedores de OEMs a obtenção de dados de dispositivos embebidos e redes de sensores heterogéneas na cloud.
No mundo ideal dos programadores de aplicações na nuvem, o hardware distribuído exigiria pouca atenção. Os programadores pretendem que o processo de ligação de dispositivos, máquinas e sistemas à cloud seja tão simples como ligar dispositivos USB ou placas de expansão PCIe a um PC: abrir a cloud, reconhecer os dispositivos, configurá-los conforme necessário e a ligação à cloud estará completa. Se os dispositivos de computação embebidos tivessem uma interface tão amigável, incluindo periféricos, seria muito simples criar automaticamente todas as aplicações e painéis de controlo necessários na nuvem com as estruturas e ferramentas adequadas. O problema é que os dados dos sensores no terreno — que variam em tamanho desde alguns bits para medições de temperatura até gigabits de dados de grandes fluxos de vídeo — são gerados por uma grande variedade de sensores e entregues numa vasta gama de estruturas de dados distintas, através de protocolos, interfaces e caminhos de transmissão heterogéneos. Sem uma lógica local capaz de processar estes dados heterogéneos e convertê-los em informação útil para transmissão, estabelecer uma ligação eficiente com a cloud torna-se praticamente impossível. A cloud permite registar qualquer estado com a mais alta densidade ou recolher apenas os dados necessários a curto ou longo prazo, por exemplo, para realizar análises de Big Data e fornecer acesso on-demand a esses dados a partir de qualquer lugar. Para que isto funcione, é necessário um gateway, seja uma plataforma de sistema virtual ou um dispositivo dedicado, onde os dados são recebidos, traduzidos, processados e transmitidos de forma transparente para as respetivas interfaces da cloud.
A importância fundamental dos gateways:
Os gateways desempenham um papel crucial na orquestração de redes de sensores, uma vez que são o nó a partir do qual a informação é enviada para o campo, a nuvem ou outros gateways vizinhos. Além da configuração de hardware adequada, também precisam de excelentes capacidades linguísticas e de tomada de decisões. Requerem lógica para recolher, analisar e transcodificar dados de sensores e decidir como utilizar essa informação. Por fim, precisam da capacidade de estruturar os dados de forma consistente, bem como de lógica para comunicação bidirecional dentro da solução na cloud, tudo com encriptação de ponta a ponta segura.
A nova API Cloud (Application Programming Interface) para gateways IoT da congatec é um exemplo de middleware e lógica para a fácil orquestração de redes de sensores sem fios. O seu objetivo é simplificar a ligação da tecnologia de computação embarcada e dos periféricos associados à cloud, fornecendo módulos de software prontos a usar que os clientes podem utilizar como modelo para desenvolver as suas próprias aplicações. Com a API Cloud da congatec para gateways IoT, as redes de sensores locais de todos os tipos podem ser integradas em qualquer solução na nuvem.
O gateway IoT comunica localmente com sensores inteligentes, processando e convertendo os dados recebidos. Os módulos de driver incorporados (EDMs) servem de interface para hardware e placas de expansão de terceiros, fornecendo a lógica que traduz os dados recebidos para a semântica específica da aplicação do gateway IoT. Os dados são transmitidos passo a passo para a cloud através de interfaces e processos de decisão predefinidos, utilizando módulos e blocos de função definidos de forma transparente que podem empregar interfaces lógicas idênticas em todas as aplicações.
O Papel Fundamental do Middleware:
O software, especialmente o middleware das gateways IoT, é crucial para receber dados do ambiente industrial, traduzi-los, encapsulá-los e transferi-los para a cloud on-demand. No entanto, é aqui que a compatibilidade geralmente falha, uma vez que, até à data, não existem APIs normalizadas para a comunicação entre sensores, gateways e a cloud. Esta lacuna precisa de ser preenchida com a normalização de APIs de cloud para gateways IoT. O objetivo é encontrar uma forma unificada de receber e processar dados localmente e, em seguida, encaminhá-los para a cloud. Afinal, só um design de API de cloud pronto a usar e, sobretudo, padronizado, permite a integração plug-and-play de diferentes ligações de sensores sem fios, como Bluetooth LE, ZigBee, LoRa e outras LPWANs, bem como protocolos com fios para automação de edifícios e industrial. Desta forma, mesmo configurações de protocolo altamente heterogéneas podem ser facilmente integradas com o mínimo esforço de desenvolvimento. O mesmo se aplica às comunicações na nuvem, naturalmente, uma vez que os requisitos individuais para servidores proprietários ou ofertas de terceiros, como o Microsoft Azure, Telekom ou Amazon AWS Cloud, também devem ser cumpridos de forma plug-and-play.
Os primeiros componentes de software a serem padronizados são os diversos módulos de função da API na nuvem. Do ponto de vista prático, o mecanismo de sensores com EDM implementado na API de cloud da congatec para gateways IoT desempenha um papel fundamental, uma vez que permite a tradução e transmissão de dados de sensores e atuadores locais para um middleware genérico e independente de protocolo. Também padroniza as medições em unidades físicas livremente definíveis e verifica o significado dos dados recebidos. Com a ligação de interface EAPI normalizada, os módulos podem fornecer parâmetros de hardware relevantes, tais como temperaturas e tensões do sistema, utilização da CPU ou deteção de roubo.
Através do seu mecanismo de regras específico para cada aplicação, o gateway envia alertas locais e aciona ações automatizadas quando determinados limites são ultrapassados ou estão prestes a ser ultrapassados. Graças ao seu mecanismo de sensores independente de hardware, os criadores de OEM podem implementar consistentemente os mesmos tipos de sensores, como sensores de temperatura, da mesma forma. Isto simplifica a configuração e aumenta a eficiência.
O que falta para além desta lógica para a ligação e abstração de hardware é uma interface de cloud padronizada que também possa ser livremente alterada dependendo do fornecedor de cloud. Para o resolver, a congatec desenvolveu um módulo de interface em cooperação com a M2MGO: o mecanismo de comunicação. Fornece comunicação encriptada com servidores ou diferentes nuvens através de ligações inteligentes com ou sem fios. Se todos os módulos de função fossem oferecidos com base num padrão aberto e independente do fornecedor, os sensores, gateways e nuvens poderiam ser livremente integrados conforme a necessidade. Funcionaria sempre.
Além da conectividade plug-and-play na cloud para o hardware, os programadores também precisam de uma solução prática para configurar gateways IoT e implementar os cenários descritos. Uma solução que se integra perfeitamente com a API Cloud da congatec para gateways IoT é a framework cloud M2MGO People-System-Things (PST). Para além da gestão de dados de dispositivos e sistemas, o PST oferece um conjunto robusto de funcionalidades para a criação de aplicações sem qualquer programação. Os utilizadores podem gerar aplicações web completas utilizando um editor de arrastar e largar. Dependendo dos dispositivos disponíveis, as aplicações móveis para utilizadores finais podem até ser criadas automaticamente, sem intervenção manual.
Estrutura do Ecossistema:
Naturalmente, uma abordagem de API em nuvem aberta como esta só pode ser tão robusta quanto o ecossistema que a suporta. Para soluções verdadeiramente plug-and-play, os principais fornecedores de computação incorporada, periféricos e cloud terão de suportar uma API na cloud, dado que cada dispositivo de hardware requer um motor de sensor dedicado e cada cloud requer um motor de cloud apropriado. Dependendo da lógica de decisão do gateway necessária, basta executar regras específicas do motor. Isto minimiza o esforço de desenvolvimento necessário para se ligar à nuvem. Nas instalações padrão, é possível implementar módulos certificados e prontos a utilizar sem escrever uma única linha de código adicional. O plug-and-play, bem como a parametrização em vez da programação, são os princípios orientadores. Se todos os módulos padrão forem instalados corretamente, o motor de sensores fornecido lê, traduz e processa os dados no gateway IoT imediatamente após a captura, utilizando a linguagem da cloud. Como resultado, o utilizador pode visualizar as informações processadas numa aplicação web gerada automaticamente, em vez de ter de programar e desenvolver individualmente todo o processo para cada sensor. No futuro, todos os dados desejados serão transferidos automaticamente para a nuvem e para o utilizador.
Vantagens da normalização
Mas a normalização oferece ainda mais vantagens: com blocos de funções normalizados, os clientes deixam de estar vinculados a um fornecedor específico. Além disso, a normalização destas APIs fornece uma base ideal para estratégias de migração de OEMs. Os programadores só precisam de conceber a sua aplicação IoT uma vez e depois podem portá-la para qualquer combinação de sensor, gateway e cloud para novas aplicações. Esta portabilidade é extremamente conveniente, uma vez que uma solução na nuvem que liga fieldbuses localmente e comunica via WLAN com uma nuvem Microsoft Azure é diferente de uma que recolhe dados localmente via WLAN ou LoRa e os transfere via 3G/4G para uma nuvem de telecomunicações. Se os gateways individuais suportarem uma API de cloud padronizada, os programadores apenas precisam de alterar o mecanismo de cloud; tudo o resto pode permanecer o mesmo. Esta é uma forma eficiente de implementar até os requisitos mais exclusivos com blocos de construção padrão e prontos a utilizar. Para dar um exemplo, aqui está um cálculo rápido: uma solução IoT com quatro redes de sensores alternativas e três ambientes de cloud possíveis para diferentes aplicações exigia anteriormente 12 implementações completamente diferentes no gateway IoT (3x4). Uma API de cloud padronizada reduz drasticamente a complexidade da tarefa, limitando-a à integração ou implementação de apenas 7 motores (3 motores de cloud mais 4 motores de sensores). Se alguns destes mecanismos já estiverem disponíveis, o esforço é ainda menor. Todas estas opções garantem também a disponibilidade das soluções a longo prazo.
Situação Atual dos Esforços de Normalização:
Considerando as inúmeras vantagens da normalização aberta para OEM e fornecedores de aplicações IoT, o Grupo de Normalização para Tecnologias Embarcadas eV (SGET) estabeleceu um grupo de trabalho há dois anos. Como resultado preliminar, o SGET apresentou o primeiro sistema de demonstração deste tipo na Embedded World 2017. O grupo está atualmente a trabalhar para finalizar a versão 1.0 do novo padrão de API na nuvem para sistemas embebidos e módulos de expansão. O objetivo é a adoção oficial da norma no início de 2018. Até lá, mais fabricantes são incentivados a participar, pois quanto maior for a base de apoio, maiores serão as probabilidades de estabelecer esta norma a longo prazo. O esforço de normalização da API na nuvem receberia um impulso significativo se, para além dos fabricantes de tecnologia incorporada, os fornecedores de dispositivos periféricos e os principais fornecedores de serviços na nuvem também endossassem esta norma aberta. Obter o apoio destas partes interessadas é, portanto, uma tarefa importante para o SGET dentro do processo de normalização.
Autores:
